W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > September 2007

Saxonica Comments on XProc last-call draft, sections 3 and 4

From: Michael Kay <mike@saxonica.com>
Date: Sat, 22 Sep 2007 20:03:39 +0100
To: <public-xml-processing-model-comments@w3.org>
Message-ID: <012101c7fd4b$492478d0$6401a8c0@turtle>

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

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

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

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

Received on Saturday, 22 September 2007 19:03:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:24 UTC