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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
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: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26751

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Michael Kay <[hidden email]> ---

Changes applied as follows. Marking resolved since this is 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.

The intended meaning was "applies to all attributes in the stylesheet where the
attribute name is in no namespace and the parent element is in the XSLT
namespace." Will clarify accordingly.

- 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.

I have capitalised the "if the" bullets as they are all complete sentences.

- 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:"

Already fixed (atomic values are now handled separately since it is not
possible to define a match pattern as a union of a selection pattern and a
predicate pattern).

- 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.
It means an xsl:try instruction that is an ancestor of the xsl:result-document
insttruction. But while the sentence is true (it may be caught be a containing
xsl:try) it is incomplete (it can also be caught by a non-containing xsl:try).
Changing it to say "... and may be caught (for example by an xsl:try
instruction that contains the xsl:result-document instruction).

- 8.3.2, 2nd example, "unvalidated tree", should this be "invalid tree" or
"non-validating tree"?
No, it means what it says: the tree that has not been validated; distinguishing
it from the other tree, which has been validated. I can't think of a better way
of saying this, and as it's only an example I propose no change.

- 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.
Agreed.

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

- 10, definition of "invocation construct", misses fn:key.
- same in C Glossary
I think this is intentional. key() is more like a variable reference; it does
not "cause" the execution of the xsl:key use or match attributes (in the sense,
for example, that try/catch could catch errors during their validation). I'm
not sure whether acc-before and acc-after shouldn't be excluded from the list
for the same reason. There are probably a number of edge cases here that could
be better defined, e.g. the interaction of accumulators and try/catch. I don't
propose to tackle that right now.

- 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
Already fixed.

- 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.
I've been looking at the table in 5.4.4 and realising it's pretty muddled about
exactly what it means when it says "initial setting". Too big a job to tidy it
up now, I'll apply the changes you suggest as a quick fix.

- 15.6, see previous point, it also applies to the last para of the opening
section
This paragraph is essentially redundant, so I've reduced it to a Note and
simplified it.

- 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)
We often talk of the posture and sweep of an operand, e.g. 1a(ii) in the same
section. I think this is legitimate: in the definition of "operand" (which we
don't often link to...) we say "an operand is a construct..", so it's
reasonable to talk of properties of the construct as properties of the operand.

- 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.
Yes. Also changed it to use U{document-node()} notation.

- 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.".
Yes it's redundant, but I think it's helpful.

- 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]".
Changed it to say "a filter expression (see [xpath 3.2.1])".

- 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)
This has been raised before, and we ended up with the references at the start
of 19.10. I don't think it's easy to improve further. "This section" is more
ambiguous than "this specification".

- 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.
I think the previous paragraph makes it clear. The error description is merely
recapitulating the previous para and its bullet points.

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