This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 3081 - Editorial suggestion for xpath-default-namespace
Summary: Editorial suggestion for xpath-default-namespace
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-04 18:31 UTC by Joanne Tong
Modified: 2006-05-04 22:44 UTC (History)
1 user (show)

See Also:


Attachments

Description Joanne Tong 2006-04-04 18:31:13 UTC
Questions were raised while writing tests for x-d-n because the text doesn't seem to be explicit enough.  Questions such as whether AVTs are affected by x-d-n even though the result of the AVT may not be, and specifically which type of names are not affected by x-d-n.

I suggest making the following (or similar) changes to section 5.2 (Unprefixed QNames in Expressions and Patterns) to clarify the text:

For any element in the stylesheet, the effective value of this attribute determines the value of the default namespace for element and type names in the static context of any XPath expression contained in an attribute of that element<new>, including attribute value templates</new>. 

The attribute does not affect other names <new>that are used solely for cross reference purposes in stylesheet-defined objects</new>, for example function names, variable names, or names used as arguments to the key or system-property functions.



thanks,
Joanne Tong
Comment 1 Michael Kay 2006-04-04 22:56:29 UTC
I personally would have thought it reasonably clear that an XPath expression between curly braces in an AVT is "an XPath expression contained in [that] attribute": though if other people feel it needs spelling out then we can spell it out.

I'm not happy about the addition "The attribute does not affect other names <new>that are used solely for cross reference purposes in stylesheet-defined objects</new>..." As written, we've listed all the places that *are* affected, and the final sentence says that if the name isn't in one of the places listed above, then it isn't affected. The "other names" referred to here is a much broader list than your clause suggests, for example it includes attribute names in path expressions, names of output methods, etc. With your change, it's not clear whether names appearing in neither list are affected or not.
Comment 2 David Marston 2006-04-05 19:26:24 UTC
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.
Comment 3 Michael Kay 2006-04-05 20:41:44 UTC
x-d-n only affects the interpretation of unprefixed QNames that appear statically somewhere in the stylesheet. It has no effect at run-time, and it has no effect on names written in the form of string literals. Perhaps that's the distinction you are grappling with.

It's also true, as you're suggesting, that the list of names it affects are essentially the names of elements appearing in source documents. For names of objects in the stylesheet (and for names of attributes anywhere), the rule is "no prefix means no namespace". For names of constructed elements, the rule is "no prefix means use the default namespace (xmlns='uri')". Type names were included, I  think, because of a feeling that types would often be in the same namespace as the input document and so should be treated consistently.

I'm not sure I understand why you draw out the content of an xsl:key element as a special case. The content consists of XSLT instructions, and they are affected by x-d-n in exactly the same way as XSLT instructions anywhere else in the stylesheet.
Comment 4 Michael Kay 2006-04-27 21:26:48 UTC
The editor was asked to propose editorial changes to remove any sources of uncertainty from the meaning, addressing the comments made above.

Suggested changes:

In 5.2 after "contained in an attribute of that element" add "(including XPath expressions in attribute value templates)".

In the last para of 5.2, change "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." to "The attribute does not affect other names, for example function names, variable names, or template names, or strings that are interpreted as lexical QNames during stylesheet evaluation, such as the [effective value] of the name attribute of xsl:element or the string supplied as the first argument to the key function."
Comment 5 Michael Kay 2006-05-04 22:44:23 UTC
The changes proposed in comment #4 were accepted by the WG and have now been applied.