[XML-SIG] SAX Namespaces

[tpassin@home.com]

Paul Prescod wrote -
> tpassin@home.com wrote:

> > * Passing along the prefix could be very useful for some people, but it
is
> > basically a convenience.
>
> **** I want to stress the following point. ****
>
> The prefix is necessary for the DOM and for XPath as well as for all
> specs that use XPath: XPointer, XLink, XSLT and Schematron.
>
> Let me say it another way: it is the right of a person writing an
> application based on the DOM, XPath or XSLT to work entirely based on
> rawnames or even just prefixes. It is an exaggeration to say that there
> is "no way to know the prefix." It is relatively easy to hard-code
> prefixes in your DTDs, and thus enforce consistent usage of them in
> documents.
>
I'm not really disputing that current apps may use the prefix as the
preferred NS designator.  I am pointing out that the Recs call for
URI/localname pairs as the key identifiers.

From the Candidate Rec for Level 2 DOM:

"On the contrary, the DOM Level 2 methods related to namespaces, identify
attribute nodes by their namespace URI and localName."

From the XPath CR:
"Some types of node also have an expanded-name, which is a pair consisting
of a local part and a namespace URI. The local part is a string. The
namespace URI is either null or a string. ...Two expanded-names are equal if
they have the same local part, and either both have a null namespace URI or
both have non-null namespace URIs that are equal."

From the Namespace Rec:
"Note that the prefix functions only as a placeholder for a namespace name.
Applications should use the namespace name, not the prefix, in constructing
names whose scope extends beyond the containing document."

The XLink CR does not mention prefixes or namespaces at all, except with
regard to the meaning of the xlink: namespace.

From the XSLT rec:
"If it has a prefix, then the prefix is expanded into a URI reference using
the namespace declarations in effect on the attribute in which the name
occurs. The expanded-name consisting of the local part of the name and the
possibly null URI reference is used as the name of the object."


From the XPointer CR:

"For example, if there is an XML document containing an element ex:y that is
in the scope of a namespace declaration xmlns:ex="http://example.com/foo",
then the following XPointer will work properly if it appears in the scope of
this declaration:

xpointer(//ex:y)

If this XPointer is moved or copied to an XML document where such a
namespace declaration is not in force or to a non-XML document, it can still
address the desired element properly if it is transformed to the following
form:

xpointer(//*[local-name()='y' and
namespace-uri()='http://example.com/bar'])"

This example shows that a prefix **can** be used in a path expression, but
it doesn't **have** to be used.  The URI can evidently always be used.


So if we want to directly support the DOM (level 2, at least), XPATH, XSLT,
and XPointer the way these recs say they are supposed to work, the primary
emphasis will be on (URI,localname).  I can't speak for Schematron.  If our
current apps don't work like this, maybe we want to look at them again.

Please note, I'm only addressing tuning the apps to directly support the
current recs/CRs.  I'm not saying they shouldn't be able to provide or use
prefixes.

Cheers,

Tom Passin