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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XML complexity, namespaces (was WG)

[ Lists Home | Date Index | Thread Index ]
  • From: james anderson <James.Anderson@mecomnet.de>
  • To: "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Fri, 19 Mar 1999 12:24:15 +0100

Richard L. Goerwitz wrote:
> Re namespaces:
> After working with them now for a few months, I can't say I'm any more
> impressed with namespaces than when I started.  Why?

Nice list.

>   --  No no matter what anyone says, they screw up validation.  --

While I agree with the general sentiment and with the detailed observations, I
don't agree with the conclusion.
When the namespace spec ascended to the status of a recommendation, I changed
our mechanism for interning symbols to conform to it. Those modifications were
non-trivial, baroque, and in some cases difficult to motivate. (except that,
"well, that's what the spec says.") I did not, however, change anything in the
validation engine. They're really separable issues.

Whatever the problems with the namespace spec may be, this one is that it
simply does not provide complete means to encode names unambiguous names in an
xml-1.0 document. This is the problem which you describe below. It's an old problem.

All aspects of which have solutions. That is, it is possible to either provide
or to infer the necessary information. Providing it is easy. But it's not
standard. Inferring it is someone more complex, but also readily doable. In
this case, only the scoping rules remain outside the standard.

>     1) because DTDs aren't namespace-aware, and therefore
>       a) don't know the difference between a defaulted element and one
>          that simply has no namespace
>       b) have no scoping mechanism to at least allow you to kludge
>          namespace defaulting by restricting elements to one or another
>          part of the syntax tree
>     2) because namespaces require you to parse attributes and values
>        fully before finishing element name processing; this is bad be-
>        cause it
>       a) makes one-pass parsing more difficult, and requires retention
>          of much more information during the parse
>       b) makes for unexpected interactions between the DTD (which may
>          provide default attributes for a given element, including
>          xmlns="" - which puts the element into a namespace)
>     3) because inherited attributes are inimical to the whole DTD
>        concept
>       a) it was bad enough that we had to put up with xml:lang and
>          such (which processing software must pass down the parse
>          tree), now the XML standard itself has inherited attributes
>          built in with namespaces

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


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

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