[Bug 26751] New: [XSLT30] Potentially editorial: (minor) ambiguities and unclarities in the text

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26751

            Bug ID: 26751
           Summary: [XSLT30] Potentially editorial: (minor) ambiguities
                    and unclarities in the text
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

The following findings, suggestions etc have been collected during the last
couple of months. Instead of submitting little bits at the time, I thought it
would essentially be more efficient to deal with multiple minor issues at once.

In order of appearance, checked against the Sept 5, 2014 internal Draft:


Ambiguities (debatable, potentially not just editorial)
- 3.14.2 para starting "This mechanism" has opening sentence "[...] applies to
[...] and to all attributes that are in no namespace". While later LRE's are
mentioned (but not data elements), it might be clearer to say "and to all
attributes that are in no namespace and are defined in this specification". Or
something along those lines.

- 3.11, opening para above bulleted list starts with "When an element...", then
each item in the list starts with non-capital "if the element" and ends with "
then the element...". Instead of "if the" I would propose to use "and the",
because otherwise the sentences do not seem to combine.

- 6.7.1, the para on built-in text copy rules talks about nodes and atomic
values, and then concludes only about the context node, which can be absent:
"The built-in template rule for text and attribute nodes and atomic values
returns a text node containing the string value of the context node. It is
effectively:"
Suggestion: "The built-in template rule for text and attribute nodes and atomic
values returns a text node containing the string value of the context *item*.
It is effectively:"

- 8.3, first list, #5: "[...]and may be caught by a containing xsl:try
instruction.". Does containing here means "wrapping", "ancestore" or "outer"?
It is not clear to me what the object for "containing" is.

- 8.3.2, 2nd example, "unvalidated tree", should this be "invalid tree" or
"non-validating tree"?

- 9.7, under "Statically known function signatures" in the table, para starts:
"The core functions defined in [FO]". The definition for "core functions" was
updated to include map functions, but the text was not. I think we should
remove "defined in [FO]" to avoid this ambiguity.

- 9.7, static expressions are also used now in shadow attributes, this notion
is not yet reflected here.

- 10, definition of "invocation construct", misses fn:key.
- same in C Glossary

- 10, definition of "invocation constructs", it looks like the closing "]"
comes too soon (should be after the dot, including all items).
- same in C Glossary

- 14.2.1, last Rule: "The current group is initially absent during the
evaluation of global variables and stylesheet parameters.". This should include
initial-value of xsl:accumulator. Same is true for fn:current-grouping-key,
fn:current-merge-group, fn:current-merge-key.

- 15.6, see previous point, it also applies to the last para of the opening
section

- 19.8.1, item 1.c.ii: "the operand is not grounded" should probably be "the
posture of the operand is not grounded" (an operand itself cannot be grounded,
its posture can)

- 19.8.8.18: 2nd para. Normally we talk of the "static type" or "statically
known item type" of a construct. This is omitted here. I think it ought to be
made explicit.

- 19.8.9, just before the examples "A pattern that is not motionless is
classified as free-ranging.". This is redundant, as in the first para of this
section we already say "The sweep of a pattern is either motionless or
free-ranging.".

- 19.8.7.6, text mentions FilterExpr (1x in whole doc), but that production
does not exist. Should probably be "a PostfixExpr[XP30] that also is a filter
expression[XP30]".

- 19.10 Definition of "guaranteed streamable" says "as defined by the analysis
in this specification.", I think this is too vague. Perhaps: "as defined by the
analysis in this specification under section 19. Streamability" (or: "as
defined in this section.", which is terminology used elsewhere)

- XTSE3430: last part of the sentence does not explicitly state that it is
meant to apply to streamed processing. I suggest: "is to handle this situation
*either* by processing the stylesheet without streaming, *or with streaming*,
by making use of processor extensions to the streamaiblity rules where
available.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 8 September 2014 00:44:05 UTC