Lists Home |
Date Index |
(I'm playing catch-up on the list. Apologies).
>Here are several off the top of my head:
> - One occurrence could be a string that contains the anatomical
>condition of a foot, perhaps in a list of body parts in a doctor's form;
>- Another occurrence could be a distance;
Hello Joseph. The start of this post is a response to your e-mail
but the rest of it is a rant against namespaces. Its not a rant
against your post!
As for the example of different occurrences of "feed".
The element structure of XML is a simple, elegant way of
contextualising chunks of text. XPath etc. give you techniques for
interacting with that context.
The element context of XML is all you need to resolve the multiple
occurrences of "feet" elements in your example.
As far as XML tools are concerned, where is the "collission"?
Does the collisson stop a WF parser checking well-formedmess? No.
Does it stop an XPATH processor winding its way through
the nodes? No.
If you need to distinguish one element from another - regardless of
whether or not they share the same element type
name - you can use the element *context* to do so.
The element structure gives you all the context machinery you
need. Namespaces simple adds more context machinery. As
pointless as it is complex.
The extra context machinery is unnecessary and extremely
counterproductive. It adds complexity in-your-face all
the way through XML application development and
Anybody who thinks this is not the case has a much better way of
writing XML applications than I have (and is keeping the details to
themselves to boot :-).
Name collision lower down than application-level semantics is a myth.
At the application level, you have the full power of the element
context model to handle it.
If you need to differentiate elements for interchange purposes, interchange
XPaths along with the instance. What's the problem?
Adding another context model - a complex context model at that - from
the UnicodeWithAngleBrackets, right the way up to the application,
is a really, really bad idea.
Its also another dreadful example of more and more *stuff* being piled
into XML without any apparent thought for how functionality can
be modularised, pipelined and otherwise kept from exploding in our
faces in one big fireball of complexity.
The alternative to namespaces? XML + XPath.
Why not? Lets explore it.
All around me I see SAXes, XPaths, DOMs etc. etc. that
are infested with namespace complexity.
I see programmers all over the map pulling tufts of their own hair out.
Programmers who strongly suspect that, in this case, the XML appointed
emperor has no clothes, but are reticent to come forward and say so.
There simply must be a better way.