OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 46 - Namespace for the document fragment representing a part


Message text written by "Sanjiva Weerawarana"
>
W.r.t. your previous note responding to my comment about scalability,
I don't think this is the right forum to debate the value (or lack
there of) of namespaces. So I will respectfully not follow-up.
<<<<<<<<<<<<

Sanjiva,

Fair enough ; -)

I'm not sure that the link from James really helps us at all.

We've moved on from 3 years ago - and the reality is there
are implementations out there in Java that have certain
behaviours - and these are causing real problems - despite
James best efforts to head this off at the pass.

You kinda sense that James was mostly trying to bolster
a tenous position and make the most of a badly dealt
hand.  The DOM memory model is the root of this, and
I always hate when the software "tail" is wagging the
real world usage.  There's never any excuse for the
case that it "has to be that way because of the software".

The notions James was articulating in that note - just 
don't hold strong enough.   The issue is determining
context - not that "part" and "part" are named the same thing,
if you know the context - there's no issues.   

But that's a whole another topic.  Clarifying context is
a huge piece of what the new technologies like CAM 
are doing.

Back to XPath - my take is a pragmatic one - all we
can do now is make sure we endorse practices that
will ameloriate the problem - we cannot undo history,
but we can avoid the same mistakes twice (hopefully!).

DW


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]