Re: [xml-dev] Re: URIs, concrete (was Re: [xml-dev] Un-ask the question)

Wow, that's brilliant, and, well, kind of twisted.  It seems like the
end result is the bad practice I've complained about, but that a
halfway-sane approach to these transformations (distributed sanity?)
might well avoid the no-namespace attribute conundrum.

SOAP's willingness to play with unqualified elements is a clear strike
against it in my book, and I think I may have to update monasticxml.org
to make clear that the kinds of practices you suggest below are
downright dangerous in part because of the kinds of twisted results they
produce.


Jim Fuller stretched his imagination with:
> ----- Original Message ----- From: "Simon St.Laurent"
> <>
> > makes sense.  All I'm getting from you is noise about global 
> attributes,
> > which my proposal doesn't affect _in the slightest_, and talk about 
> OOP
> > best practice.
> 
> I agree with simon that starting out with something like;
> 
> <test:jim hat="" test:hat=""/>
> 
> is pretty inane, even with some of the more difficult use cases
> representing
> | network | relational | object | multilingual | hierarchical data
> | using
> hierachical model as imposed by xml in general. A simplistic scenario
> ( apologies for the slightly applicable xml..... )
> 
> I start a multi node SOAP process which delivers data about your
> family and performs a standard transformation with accumulated xml
> and current xml, hopping from SOAP node to SOAP node.
> 
> we start off with this xml
> 
> <other:family other:surname="says">
> 
> <other:person forename="simon" other:hair="black" other:age="35"/>
> 
> </other:family>
> 
> then we hop to the next soap node and apply our std XSLT transform
> with the data provided at this SOAP node
> 
> <them:family them:surname="you">
> 
> <them:person forename="dare"  them:age="28"/>
> 
> </them:family>
> 
> which takes all local name common element and attributes and places
> their values in a list like so;
> 
> <family surname="says,you"> <person age="28,35" hair="black"/>
> </family>
> 
> Lets say I go through a bunch of SOAP nodes, so I am not interested
> in putting a namespace on these values, as this is interim
> processing. As I go through I keep on applying a transformation to my
> new bit of xml and my old bit of xml ( so I always have 2 nodesets ).
> 
> now I have instructed for the target SOAP reciever to send the result
> back to me, whereby I merge the data with this xml snippet putting
> attributes .
> 
> <me:family me:surname="">
> 
> <me:person me:hair="none" me:age="34"/>
> 
> </me:family>
> 
> and now I match merge my using another piece of trusty XSLT
> 
> <me:family me:surname="fuller" surname="says,you">
> 
> <me:person me:hair="none" me:age="34" age="28,35"
> hair="brown,black"/>
> 
> </me:family>
> 
> of course there is nothing preventing me from slapping a namespace on
> at the very end...something temporary, but this step could just as
> well be yet another interim SOAP node. This could also be a process
> that informs the current soap node of important data ( best fitness
> of a generation, for example ), not just a 'me' thing.......
> 
> Having no namespace may be useful in in these situations, as one
> could expect the presence of a namespace implies strict validation,
> whereas none, implies just basic well formedness and valid xml; or a
> default node handling in general. Possibly there are some perf
> aspects to this eschewing of namespace. Attributes and elements with
> no namespaces are practical in generic handling situations, and could
> be used in predicting next SOAP node, etc etc etc..... There are
> other scenarios out there, I just don't think that we have enough
> experience with some of the more complicated SOAP MEP's and peer to
> peer situations that may arise in the near future, that could take
> advantage of this 'defect'.
> 
> so if we take our initial example
> 
> <test:jim hat="" test:hat=""/>
> 
> its not the hat you know, its the hat you don't know...............
> 
> cheers, jim fuller
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com