[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>
> 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
>
the programming problem is an artifact of the misconception that names in a
namespaced world need be modeled at the application level as tuples. this is
no more true than would be the claim that names in a non-namespaced world need
to be modeled at the application level as unicode scalar value tuples.
> In other words namespaced elements are tuples after a kind.
if one insists on modeling them that way, one is making ones own problems.
> 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)
not if xpath expressions are parsed in the correct dynamic context. if the
xml-dev archives are alive, i've posted notes on this topic (and that of qname
decoding) way back when.
>
> 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..
in this regard, maybe one should consider whether the sax interface and the
sax processing model is all (or perhaps _is_) that one needs for working with namespaces.
>
> After that try programming with XPaths against namespaces - the sort
> of code simplicity Paul is after will be awkward with XPaths.
cl-xml includes a first cut xml-path processor. it adds to the standard
parsing protocol that xml path expressions are interned in the parser's
dynamic context. from that point on, the only aspects of the processor - and
therefor of application code, which are concerned with lexical properties
(prefixes, namespace names, local parts) are those which the xpath standard
stipulates must be present - eg to match on local part or on namespace name only.
everything else can be expressed in terms of abstract names. no tuples. no
lexical properties.
> 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?
no navigational code needs to be expressed differently "with and without"
namespaces. if a given substrate requires that, then it is the wrong one for
the task.
>
> In turns out that you can't without incurring a development cost.
true, but only in that one would need to fix what appears to be an
inappropriate document model.
> 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,
it must be that i do understand what this is intending to claim, as, as i do
understand it, i have thousands of lines of code lying around here which
disproves it.
> 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.
please amplify. it is not clear how the grammar places this constraint on the model.
>
> - socially, it seems people don't want deal with URIs as element
> names at the syntax level.
there is no reason that they should have to.
...
|
