Re: The Catalog of Vague, Draft 2

[Eduardo Gutentag <eduardo.gutentag@eng.sun.com>]

I'd like to be sure I'm not making any mistakes here: does the TC want me (or Scott?)
to present the following to the XSL WG in its upcoming Sept 20-22 face-to-face
meeting, or is it still under development? The word "attempt" below is a bit 
ambiguous ;-)

Eduardo


David_Marston@lotus.com wrote:
> 
> Here is the second attempt to list all the areas where the XSLT and XPath
> Recommendations are not precise enough for the OASIS conformance committee
> (or XSLT processor developers) to tell what is correct behavior. Please
> send corrections and additions to me. Each item has a handy (?) mnemonic
> label.
> 
> This list includes vague areas that we already know have been brought to
> the WG. XPath items occur at the bottom and have "XPath-" at the start of
> their mnemonic.
> 
> GROUP 1. Still planned for submission to WG
> PART 1A. Policy questions
> [attrib-set-merge] In the process of merging same-named attribute sets,
> must each set to be merged be individually resolved with respect to its own
> attributes, including any use-attribute-sets it carries, before the merger
> takes place?
> [attrib-set-not-exist] Is an attempt to use-attribute-sets with a
> non-existant set an error, ignorable, or developer's choice between those
> two?
> [copy-namespace-current] If the current node is a namespace node, is there
> any discretion about where <xsl:copy/> puts it in the result? Is it
> affected by exclude-result-prefix?
> [copy-namespace-attribute] If xsl:copy is applied to a namespaced
> attribute, and the namespace in question would not already be in scope in
> the result, is there any discretion about where <xsl:copy/> puts the
> namespace node in the result? Is it affected by exclude-result-prefix?
> [excluded-prefix-needed] What should be the effect of an attempt to emit an
> element or attribute bound to a namespace on the list of excluded
> namespaces?
> [fallback-top-level] Can xsl:fallback be implemented inside a top-level
> "extension" element? If so, must it be detected and instantiated as with
> instructions?
> [func-system-property-namespace] What rules apply to use of either the
> default or xsl namespaces on arguments to system-property (if the processor
> developer wishes to add more properties)?
> [key-unique-name] Since "each key name may be thought of as distinguishing
> a separate, independent space of identifiers", would multiple xsl:key
> declarations with the same key name be allowed? If so, how do the multiple
> declarations interact?
> [namespace-alias-intermediate] Should the namespace-alias be applied upon
> first creation of the nodes? (Ref.: Kay, p. 235)
> [namespace-alias-result-prefix] Should the result-prefix in
> namespace-alias, if not #default, be the exact prefix used in the output?
> [sort-NaN] Where should strings that cannot be converted to number values
> be placed in ascending and descending numeric sorts? The relative order of
> the strings is not in question, rather the question is whether they appear
> in a clump before/after the lowest number, or always at the beginning or
> end regardless of sort order.
> [source-notations] What should the XSLT processor do about "notations" in
> the source document? (Ref.: Kay, pp. 64-65) This question is now being
> restricted to the effects on the tree: position(), count(), etc.
> 
> PART 1B. Requests for explicit statements
> [for-each-variable] Can xsl:variable inside a for-each loop be set to a new
> value on every iteration? Current verbiage saying "template is
> instantiated" may cover this, but an explicit statement is useful.
> [func-document-second-empty] If document() is called with two arguments and
> the second is an empty node-set, should the second argument be ignored?
> [number-NaN] If xsl:number is called with a value set to positive or
> negative infinity, or any string that cannot be converted to a number, how
> should it be formatted?
> [number-negative] Should xsl:number render a negative number (specified in
> value), even in alphabetic and Roman-numeral formats?
> [number-zero] Should xsl:number emit a zero, even in alphabetic and
> roman-numeral formats?
> [sort-case-order] Does the case-order attribute of xsl:sort pertain to
> ascending order, and its opposite to descending order?
> [XPath-ceiling-NaN] Should ceiling() of any string that cannot be converted
> to a number return NaN?
> [XPath-ceiling-negative-fraction] Should ceiling(-0.1) return positive or
> negative zero?
> [XPath-contains-main-empty] If the first argument to contains() is empty
> and the second argument is non-empty, should false be returned? Given that
> every string contains the empty string, does the empty string contain
> itself? (In other words, does contains("","") return true?)
> [XPath-floor-NaN] Should floor() of any string that cannot be converted to
> a number return NaN?
> [XPath-negative-zero-multiply] Is the product of -0 and any non-zero number
> -0? Does (-0)*0 equal -0? Does (-0)*(-0) equal 0? Does (-0) div {any
> non-zero number} equal -0?
> 
> GROUP 2. Not so vague after all, with answers
> [attrib-after-comment] When populating an element, should it be a required
> error to invoke xsl:attribute after xsl:comment? Developer's discretion:
> error/ignore.
> [attrib-after-PI] When populating an element, should it be a required error
> to invoke xsl:attribute after xsl:processing-instruction? Developer's
> discretion: error/ignore.
> [choose-unselected-when-error] The xsl:when cases in a choose must be
> selected in document order, but a multi-threaded processor might evaluate
> the when tests in parallel. Must the effects of all unselected when tests
> be neutralized? Specs should not address "side effects" as long as WG
> commits to having no side effects in any function defined in the specs.
> Authors of extension functions should beware.
> [func-document-self-include] Does document("") refer to the containing
> stylesheet without included stylesheets? Yes; see the verbiage about
> "exactly the same as if the XML document containing the stylesheet was the
> initial source document" in section 12.1.
> [include-position] Should xsl:include occurring after other top-level
> elements (especially xsl:template, xsl:param, xsl:variable) confer all the
> effects of its elements occurring later in the including stylesheet? Yes,
> "children...replace the xsl:include element" covers it.
> [message-full-template] The syntax of xsl:message shows content: template.
> Does this include xsl:element, etc.? Since there is no explicit
> prohibition, as there is for xsl:attribute, then anything goes. Downstream
> processing may not be able to handle everything, but that's not an XSLT
> problem. I have asked for an enhancement in this area to provide better
> control.
> [output-text-newline] Should treatment of new-line characters be prescribed
> for the text output method? This would have to be a feature request.
> [pattern-document] Should the document() function be explicitly banned from
> match patterns? The syntax already shows that it's banned from all the
> axis/step and NodeTest stuff, but allowed in the predicate.
> [variable-top-level-full-template] When xsl:variable and xsl:param are used
> as top-level elements, they can contain template instructions. Is there any
> way in which these instructions are more restricted than the same
> instructions in xsl:template? No, you can use xsl:element and the like.
> Specifically, is xsl:fallback available? Yes.
> [with-param-full-template] The syntax of with-param shows content:
> template. Does this include xsl:element, etc.? Yes, same as xsl:variable
> above.
> [XPath-concat-one-node-set] If concat() is given one argument consisting of
> a node-set, why not concatenate the string values of all the nodes? (Note:
> some processors currently allow this.) This would have to be a feature
> request.
> [XPath-string-length-diacriticals] Should string-length() determine when
> diacritical marks are not distinct characters? No, processor should play
> stupid.
> [XPath-substring-diacriticals] Should substring() determine when
> diacritical marks are not distinct characters? No, processor should play
> stupid.
> 
> GROUP 3. Mike Kay items that I think are not vague
> (p. 84) Some behaviors of round() are not specified. If so please be more
> exact.
> I sent a query to Mike Kay.
> (P. 143) What is "imported into" when xsl:apply-imports is invoked in a
> template in a stylesheet somewhere down the import tree? I don't know of
> any ambiguous situations.
> (P. 149) Multiple evaluations of with-param involving a function with a
> side effect? Same response as choose-unselected-when-error above.

-- 
Eduardo Gutentag               |         e-mail: eduardo@eng.Sun.COM
XML Technology Center          |         Phone:  (650) 786-5498
Sun Microsystems Inc.          |         fax:    (650) 786-5727