- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Sep 2014 10:19:39 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26751
Michael Kay <mike@saxonica.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Michael Kay <mike@saxonica.com> ---
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.
Received on Wednesday, 10 September 2014 10:19:41 UTC