nasty namespace issue (was RE: Is minimalism a goal?)

DaveP wrote:
> Primary goal is the 80%, for simple, non namespace documents
> that many users are playing with today. No transformation goal,
> simply access using xpath.
>

If we're going to leave out namespace-aware documents, we might as well call
it a day, because no one will be able to use the API. Namespaces have become
part of core XML and cannont be ignored. I strongly believe that namespace
support must be included to make this API useful. Although it's going to be
hard to decide on some of the details, it's well worth the time.


Because there is no other document in-play (as with XSLT), theres a nasty
issue with default namespace declarations that we must consider. I'm not
sure about Oracle's implementation but MSXML displays slightly incorrect
behavior when dealing with this situation. For example, if you have a
document with a default ns decl:

<foo xmlns="urn:foobarbaz">
   <bar>
      <baz baq="booz"/>
   </bar>
</foo>

And you use the following expression: /foo/bar/baz, MSXML will actually
return the baz node, which is incorrect according to XPath 1.0. The XPath
spec states that when expanding names in an XPath expression, default
namespace declarations are *not* used. So in the expression /foo/bar/baz,
foo, bar, and baz belong to no namespace. Hence, when applied to the
document above, it should return an empty node-set (because foo, bar, and
baz all belong to the urn:foobarbaz namespace). If you check XT or Xalan's
implementation, they behave properly in this case.

However, in MSXML's defense, one could argue that this is a simpler and more
intuitive solution - because that's probably what I wanted anyway ;) If
MSXML did this according to the spec, anyone using default namespace
declarations is kind of stuck...there is no way to query the document.

If you're using XSLT, you can simply include a namespace decl in the
stylesheet for the default namespace decl of the queried document like this:

<xsl:transform xmlns="http://www.w3.org/1999/XSL/Transform"
               xmlns:f="urn:foobarbaz" version='1.0'>
...
    <xsl:for-each select="/f:foo/f:bar/f:baz">
...
</xsl:transform>

In this situation, the evaluation works properly.

If we want this API to conform 100% with XPath 1.0, we're kind of stuck when
dealing with default namespace declarations. But if we care more about
usability, MSXML's approach is more straightforward.

Comments?

-aaron

Received on Friday, 5 May 2000 13:50:48 UTC