Lists Home |
Date Index |
Joshua Allen wrote:
> 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)
This doesn't arise in practice. It's a corner case. Tool vendors need to
handle it, but honestly the API complexity of allowing streaming
attributes argues against this approach, even if it were possible to
> 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.
InnerXml is an ugly, non-standard Microsoft hack. Eliminate it. Problem
solved. Don't blame XML for your own mistakes.
Elliotte Rusty Harold email@example.com
XML in a Nutshell 3rd Edition Just Published!