RE: Wording of XPath relative namespace URI errata

Hi James,

I think the problem is broader than just the undefinedness of comparisons to
namespace URIs.

It is possible (e.g. with Michael Kay's saxon) to use different processors
to parse an XSLT and its input.  Therefore, it is at least conceivable that
if the input document uses relative URIs, then element matching will not
work.  For example, suppose the XSLT processor absolutizes URIs and the
input processor doesn't.  Then the input:

<Signature xmlns="../foo"/>

will not be matched by

<xsl:template xmlns:ds="../foo" match="ds:Signature"> ... </xsl:template>

John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675 <>

-----Original Message-----
[]On Behalf Of James Clark
Sent: Monday, September 11, 2000 9:53 PM
Subject: Wording of XPath relative namespace URI errata

The currently proposed wording for the XPath errata dealing with
relative namespace URIs at [1] (under Section 5 and Section 5.4) says
in effect that relative namespace URIs can get munged in an
implementation-dependent way; however, XPath expressions can still be
well-defined on a document containing relative namespace URIs, provided
that the evaluation of the expressions doesn't depend on the value of
any relative namespace URIs.

However, the wording suggested by [2] would make for a broader
undefinedness: in effect, the behaviour of the entire spec when there
are relative namespace URIs becomes undefined.  The wording here is
suggested for "new" specifications, which doesn't appear to cover the
XPath errata.

My question is: does anybody think the XPath wording should be changed
to use a wording similar to [2]?



Received on Wednesday, 13 September 2000 19:24:25 UTC