[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: URIs, concrete (was Re: Un-ask the question)

• To: "Simon St.Laurent" <simonstl@s...>
• Subject: Re: Re: URIs, concrete (was Re: Un-ask the question)
• From: "James Fuller" <james.fuller@o...>
• Date: Thu, 1 Aug 2002 03:46:19 +0100
• Cc: <xml-dev@l...>
• Organization: o-iDeveloper ltd.
• References: <r01050300-1015-C437F92DA4E411D693BB0003937A08C2@[192.168.124.21]>
• Reply-to: "James Fuller" <james.fuller@o...>

----- Original Message -----
From: "Simon St.Laurent" <simonstl@s...>
> 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

• References:
  • RE: Re: URIs, concrete (was Re: Un-ask the question)
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: so many options no idea where to begin
• Previous by thread: RE: Re: URIs, concrete (was Re: Un-ask the question)
• Next by thread: assigning semantics to XML, Re: Re: URIs, concrete (was Re: Un-ask the question)
• Index(es):
  • Date
  • Thread