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] Partyin' like it's 1999

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Robert Koberg [mailto:rob@koberg.com]

> I don't get the /problem/ with namespaces.

Joe English and Bill de Hora have discussed some issues.  Default
namespace leads to dual "modes" of parsing, don't apply to attributes (I
agree with Joe, would rather just have everything be an opaque string).

No way for a parser to return a single attribute value without parsing
all the way to the end of the start tag.  For example, if you have:

<foo x:id="a" y:id="a" ...insert a bajillion attributes here...
xmlns:x="foo" xmlns:y="foo">

You have malformed XML right at the beginning, but the parser doesn't
know to throw (and cannot even accurately report the first or second
attribute) until it has parsed a bajillion other attributes first.  Why
is it allowed for the xmlns to come *after* the first use of the prefix
anyway (order of attributes doesn't matter, so to hell with perf)

What if the xmlns declaration is on an ancestor node, and you call
.InnerXml on DOM from a child node.  Should the .InnerXml represent the
text content of the subtree, in which case it would lose the namespace
decl if written to text, or should it insert an extra xmlns decl?  You
get into all sorts of crazy situations; dumping entire set of NS decls
in scope on XSLT output, generating bogus prefixes on output.

QNames in content are another abomination brought on by namespaces.

And then we have the example of people doing just fine with XML without
ever putting their data in any namespace at all.  What a mess.


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

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