OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Vocabulary Combination and optional namespaces

[ 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS