26751 2014-09-08 00:44:03 +0000 [XSLT30] Potentially editorial: (minor) ambiguities and unclarities in the text 2015-10-29 09:50:36 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 111150 0 abel.braaksma 2014-09-08 00:44:03 +0000 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. 111335 1 mike 2014-09-10 10:19:39 +0000 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.