- From: Michael Kay <mike@saxonica.com>
- Date: Sat, 22 Sep 2007 20:03:39 +0100
- To: <public-xml-processing-model-comments@w3.org>
1. Editorial. Section 3.4 In the example "Specified by source", should 'the "document" input' read 'the "source" input'? 2. Clarification. Section 3.4 "Specified inline". What are "ignored namespaces"? Ah, I see section 3.6 explains - a forward reference would help. 3. Clarification. Section 3.4 talks about binding a sequence of documents, but all the examples bind a single document (except perhaps "Specified by source", though it doesn't mention the possibility). It would be useful to have an example that binds a sequence. Ah, I see there's a note in the last paragraph. 4. Minor technical. Last para of 3.5. It might be useful to qualify "behave differently". The phraseology in section 3.7 is much more carefully drafted. 5. Editorial, section 3.6, par 2: there are two "if" conditions in the paragraph, and it is not immediately clear which one the "otherwise" relates to. 6. Spelling, section 3.8, "grammer". (Generally, the language in this section is a bit too informal for my taste: I think I know what "interpret per spec." means, but it doesn't sound very dignified.) 7. Technical, section 3.9, "It is a static error (err:XS0037) if any step contains text nodes that do not consist entirely of whitespace." This shouldn't apply in cases where for example the step contains an inline XML document or stylesheet. 8. Technical, Section 4, (Problem noticed here but occurs earlier). The definition of "last step" seems inadequate: [Definition: The last step in a subpipeline is the last step in document order within its container. ] I'm not sure what "its container" refers to (whose container?). And I think it's referring only to steps that are "immediately contained", ie. not to steps within a subpipeline of the subpipeline. 9. Typo, section 4.1, "when the it has been imported". 10. Editorial, section 4.2, "A portion of each input document can be selected using the select attribute". Presumably this is the select attribute of the p:iteration-source element. 11. Technical, section 4.2 "Each subtree selected by the p:for-each from each of the inputs that appear on the iteration source is wrapped in a document node". The double "each" seems confusing. A subtree will generally be selected from one of the inputs, not from each of them. I think it means that if you are processing a sequence of four documents, and you select three elements from each one, then you create a sequence of 12 documents that wrap these 12 elements. (Also, this seems to assume the select expression is selecting elements, or perhaps text nodes. What if it selects attributes, or document nodes?) (Also, "wrapping" a node isn't explained. It would seem to involve making a copy. What are the exact semantics, for example the handling of namespaces?) 12. Clarfication, section 4.2. What does the word "aggregated" in the last para mean? The word suggests combining several documents into one, I don't think this meaning is intended. 13. Technical, section 4.3. It is not explained what p:viewport does if the match pattern matches two nodes, one of which is an ancestor of another. (Suggested solution: a node is treated as not matching the pattern if it has an ancestor that matches the pattern). It's also not clear what happens if the match pattern matches an attribute: how can you replace the attribute node with a document node? 14. Technical, section 4.4.2. "It is a dynamic error (err:XD0020) if the value of the test attribute is not a valid XPath expression.". This seems most odd. Why a dynamic error rather than static? And why is this stated here and not in other places where XPath expressions are used? 15. Clarification, section 4.4. The use of p:xpath-context isn't well explained. An example might help. I'm left completely baffled as to what it's trying to achieve. Michael Kay Saxonica
Received on Saturday, 22 September 2007 19:03:53 UTC