[Bug 3081] Editorial suggestion for xpath-default-namespace

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3081


david_marston@us.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david_marston@us.ibm.com




------- Comment #2 from david_marston@us.ibm.com  2006-04-05 19:26 -------
The main point of doubt arose from the end of 5.2:
The attribute does not affect other names, for example function names, variable
names, or names used as arguments to the key or system-property functions.

It actually should affect the first argument of key() until the point that the
expression is reduced to a single string, which must be a valid XML name. Then,
if that string is an NCName, it should not have an effect. That way, it will
sync up with xsl:key/@name, where x-d-n does not have an effect. It should
always affect the second argument to key(), even if typed as xs:NAME, because
that argument is not being used as a cross-referencing name. (But it is being
used as a value to be tested against @use values; see below.)

I think the WG intends the same about AVTs: x-d-n affects what is inside the
braces, but once that is reduced to an NCName, it does not affect the name.

It would be useful to say something at 16.3.1, addressing @name briefly,
because there is also potential vagueness between the effect of x-d-n on @use
vs. the sequence constructor as content. It's clear enough that x-d-n affects
@use as an expression, and @match as a pattern also, but its effect on the
content constructor should be clarified. It should affect the expressions found
in the content constructor (e.g., xsl:when/@test), but not the resulting values
nor resulting @use values, should they happen to be valid NCNames.

BTW, I did not feel confident that the list of items affected by x-d-n at 5.2
was an exhaustive list. Now that I see the comments in this bug entry, I think
the policy regarding path expressions is that it only affects source-facing
names, not output-facing names. I think that it affects type names facing both
ways.

Received on Wednesday, 5 April 2006 19:26:38 UTC