Re: The Catalog of Vague, Draft 1

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

Committee members,

I'd be more than glad to transmit this (or subsequent drafts) to the XSL working
group at their upcoming face-to-face meeting, September 20-22.

It would be most convenient if the [mnemonic-label] for each item had
also a reference to a section/subsection in the spec, so XSL working
group members could find the reference quickly and unambigously.

For instance: [attrib-after-comment:7.1.3]

I must confess, though, that I'm a bit surprised that you've included
[attrib-after-comment] and [attrib-after-PI] in the list of ambiguities
in the XSL spec. 

Section 7.1.3 explicitely says that 
--
The following are all errors:

                      o    Adding an attribute to an element after children have been added to it; implementations
                            may either signal the error or ignore the attribute.
--

According to production 43 at http://www.w3.org/TR/REC-xml#NT-content, 
comments and PIs have the same status as other children, so
I'm not sure why this is perceived as ambiguous.

Similarly, I wonder what prompted [message-full-template] - Section 13 seems to
be pretty unambiguous to me: 
                 "...The
                  content of the xsl:message instruction is a template. The xsl:message is instantiated by
                  instantiating the content to create an XML fragment. This XML fragment is the content of the
                  message."

The above, read in conjunction with the definition of % template, which containst %instructions,
which contains xsl:element, seems rather clear to me. What am I missing?

Please understand that I'm not pushing back, I'm just trying to make sure that
what this TC submits to the XSL WG is clear and well-reasoned so as to avoid
any misunderstandings.

Thanks

Eduardo


David_Marston@lotus.com wrote:
> 
> Here is my first 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. This
> differs from the previously-published list of discretionary items because
> those were explicitly granted by the specs. These are "discretionary" only
> insofar as a developer has to use their own discretion in interpreting the
> specs.
> 
> This list draws upon our experience at Lotus plus vagueness itemized in
> Mike Kay's book. I expect that a few more items will emerge, and the XSL
> Working Group may say that some of the items below are actually answered if
> I would only read the spec more precisely. Scott or Eduardo, let me know if
> you take this list to the WG. All: please send corrections and additions to
> me.
> 
> Each item has a handy (?) mnemonic label. I use the term "NaN-string" as an
> abbreviation for "any string that cannot be converted to a number," which
> of course includes "NaN" itself.
> 
> [attrib-after-comment] When populating an element, should it be a required
> error to invoke xsl:attribute after xsl:comment?
> [attrib-after-PI] When populating an element, should it be a required error
> to invoke xsl:attribute after xsl:processing-instruction?
> [attrib-set-merge] Must the process of merging same-named attribute sets be
> completed before the set is used anywhere, including in the definition of
> other attribute sets? What if an xsl:include is situated between two
> xsl:attribute-set elements?
> [attrib-set-not-exist] Is an attempt to use-attribute-sets with a
> non-existant set an error, ignoreable, or developer's choice between those
> two?
> [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?
> [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?
> [for-each-variable] Can xsl:variable inside a for-each loop be set to a new
> value on every iteration?
> [func-document-self-include] Does document("") refer to the containing
> stylesheet without included stylesheets?
> [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?
> [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)?
> [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? If
> not, which elements in the included document act as if they were in
> positions in the including stylesheet other than the position of the
> xsl:include?
> [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?
> [message-full-template] The syntax of xsl:message shows content: template.
> Does this include xsl:element, etc.?
> [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?
> [number-NaN] If xsl:number is called with a value set to positive or
> negative infinity, or a NaN-string, 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?
> [output-text-newline] Should treatment of new-line characters be prescribed
> for the text output method?
> [pattern-document] Should the document() function be explicitly banned from
> match patterns?
> [sort-case-order] Does the case-order attribute of xsl:sort pertain to
> ascending order, and its opposite to descending order?
> [sort-NaN] Where should NaN-string values be placed in ascending and
> descending numeric sorts?
> [source-notations] What should the XSLT processor do about "notations" in
> the source document? (Ref.: Kay, pp. 64-65)
> [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? Specifically, is xsl:fallback available?
> [with-param-full-template] The syntax of with-param shows content:
> template. Does this include xsl:element, etc.?
> [XPath-ceiling-NaN] Should ceiling() of any NaN-string return NaN?
> [XPath-ceiling-negative-fraction] Should ceiling(-0.1) return positive or
> negative zero?
> [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.)
> [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 NaN-string return NaN?
> [XPath-string-length-diacriticals] Should string-length() determine when
> diacritical marks are not distinct characters?
> [XPath-substring-diacriticals] Should substring() determine when
> diacritical marks are not distinct characters?
> 
> Here's one that I cannot confirm:
> [XPath-round-details] Mike Kay (p. 84) says that some behaviors of round()
> are not specified. If so please be more exact.

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