[
Lists Home |
Date Index |
Thread Index
]
Hello Simon,
This example was attempting to say that local names, not just their values
are meta data too; some sort of common local name analysis......
What you are saying is that a world with no namespaced xml in general, is
not a world that you want ? Which changes the focus from attributes ( and
all the silly nuances ) to something more generic like namespaced xml versus
no namespaced xml. Yes I'm slow on the uptake or maybe wrong......
There may be perfectly valid reasons for generating a no namespaced element
( and/or attribute )...tried representing the intersection of many
namespaced elements and attributes with no namespaced elements and
attributes, for example.
The example is admittedly reaching, but in a real sense, no namespaced xml
is out there ( in fact it may be useful to represent data this way )....and
as I said I think its inane to start off with something like <test:jim
hat="" test:hat=""/> but with a little imagination I can easily see it as a
result of some complicated process that generically handles unknown elements
and attributes.
In your world of fully qualified namespace attributes and elements you would
never have to change the spec, because you would never encounter the
situation. Be it a defect or a design aspect, best practice takes care of
the problem ( by using namespaces ), I see no need to change the spec until
it is proven that 'it is broken'. We may lose a powerful idiom...without
even knowing how to use it ! Or we may never use it and never miss it.
cheers, jim fuller
ps: and if you are horrified by the lack of architecture in that example,
you should see my previous software ! glad you aint paying the bills hehehe.
----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: "James Fuller" <james.fuller@o-idev.com>
Cc: <xml-dev@lists.xml.org>
Sent: Thursday, August 01, 2002 4:02 AM
Subject: 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"
> > <simonstl@simonstl.com>
> > > 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
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
