[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote:
>
> | Paul Prescod:
> | And anyhow, it should be the responsibility of infrastructure to track
> | the namespace environment. XSLT is an example of infrastructure that
> | does a pretty good job.
>
> But your Python code was exposed to the problem even in the simple case.
> I'll grant that the changes were simple, but why did anything have to be
> changed at all?
The programming problem boils down to this. In a non-namespaceed
world, XML elements are self-contained:
elementname
In other words, XML elements are strings, after a kind. In a
namespaced world, they are not:
elementname, namespace, elementprefix
In other words namespaced elements are tuples after a kind. You're
told to only care about the first two members, but sometimes you do
need to care about the prefix (that prefixes have no import is a
myth, because XPath makes it a myth)
For a direct example of how the structural issues of using a tuple
affect code, see the SAX startElement call, and try operating on
various bits of markup with a handler. For anyone that has Dave
Brownell's SAX book, he has a good discussion on this. Or go through
the xml-dev archives..
After that try programming with XPaths against namespaces - the sort
of code simplicity Paul is after will be awkward with XPaths. Using
an XPath is almost always preferreable to rolling out yet another
DOM iterator or SAX stack or some hokey findByFoo API call - until
it comes to using namespaces, where managing embedded prefixes can
make a NodeList look decidely attractive. Try something like Xalan
or Pyana with and without namespaces to get an idea of the differences.
All the while ask yourself, how to I manage this code with and
without namespaces? How do I get the code under control?
In turns out that you can't without incurring a development cost.
After dealing with this stuff for the last few years, I believe that
cost isn't worth it, and where it might be worth it, it's proabably
for corner cases that have no business being generalized into the
bulk of programming work with XML. So naturally when I see someone
coming at me with document design using namespaces, I'm want to
resist that design in favour of something simple and cost-effective.
There is no canonical (self-describing) form for for a namespaced
element, ie there is no way to treat it like a regular XML name so
the code reflects the difference. You can't get to such a form for a
namespaced element for two reasons
- technically the XML grammar won't allow it.
- socially, it seems people don't want deal with URIs as element
names at the syntax level.
The first one is something of a show stopper in terms of code
management. The second one is entirely understandable, but you pay a
cost for the managing abbreviated forms. Either way you have to
infer a namespaced element's true name, since it's not directly
declared in the markup any more. To my mind this tacit name is less
self-describing than a regular element name. XML Namespaces are not
without irony.
The namespace tax isn't offering anything. My position on working
with XML Namespaces in sofware is analogous to a RESTafarian's
position on SOAP-RPC - why on earth would you want to tunnel like
that? The differnce is that XML Namespaces tunnel nouns through
markup and SOAP-RPC tunnels verbs through protocols. To claim
they're simple and should be no cause for concern is wrong and
irrelevant. That position won't be changing until someone shows me
either that namespaces are neccessary in the general case (I'm
wrong) or XML grammar is changed to allow URIs are element names
(XML is wrong).
Bill de hÓra
|
