RE: comments on XProc last-call draft

>2) Editorial: Example 1, 4 (and possibly other) features step named like
actual p: tags ("pipeline").
>Steps inputs and outputs are all names "source" and "result".
>I found it rather confusing, at least not until reading almost entire spec.
Naming them
>like "main", "xslt-input" and etc. would safe quite some confusion.

I disagree. Such naming convention is vital for the intuitiveness from a
pipeline authors' point of view. And if you, as an implementer were able to
figure it out, after reading the spec and checking the examples, then it
mustn't be that difficult to grasp, and thus - not worthy to change.

>3) Definitions: Definitions of "containers" and "ancestors" is not very
clear, given the fact that "ancestor" is not defined at all.

The element containing a sub pipeline is the sub pipeline's container. I
don't see how can this be made more clear and accurate at the same time.

As for "ancestor", that's not a term defined in XProc. XML (or XPath... I'm
not sure) defines it. It means all elements contained in a certain element.
Every XML and/or XPath tutorial explains this when it explains XPath axis.

>5) Document model: in several places (p:for-each,p:viewport ant etc.) term
"document node" is used. 
>This suggests DOM Document object, right?
>If so, what would be the way to execute pipelines against large documents?
If not, what exactly is to be understood?

I don't think it does. Saying "document node" is the same as saying "element
node" or "attribute node" i.e. it specifies the type of node that must (not)
be expected/returned/matched/whatever. "Node" again is an XML term, not a
DOM term (though I don't see it in the XML spec, so I'm not sure which spec
defined it... still, it's not a DOM centric term). It's often used in the
XSLT specification or the XPath specification, and yet doesn't enforce DOM
usage.

>7) "p:try/catch": Any particular reason why "p:finally" is not part of the
construct? This is well know paradigm and
>missing "finally" is a bit confusing at first sight.

I don't have experience in that many languages. The ones in which I do don't
use "finally", so I'm a little lost. What does that do in which programming
languages and how would you translate those semantics into XProc?

>8) "p:serialize" : I'd happy to see also "exclude-prefixes" (after XSLT).

That's needless. Steps don't serialize their output and when XProc does, it
only serializes the declarations that were in the DOM at that moment. Even
if I'm wrong about this one, I think you can still execute an XSLT
transformation to exclude those prefixes.

>9) "p:pipe" : Aren't there too many pipe names mentioned: pipeline,
subpipeline, pipeline libraries, p:pipeline, p:pipeline-library, p:pipe.
>For example "p:connect" or "p:bind" would do much better.

p:pipe makes perfect sense if you ask me. p:pipeline defines a line of
pipes, and p:pipe refers to a single one of those pipes. p:bind doesn't make
sense as p:pipe defines a "binding" and the same thing do p:document and
p:inline. Having this element named "p:bind" would create ambiguity. And
"p:connect" won't make sence unless it has two things to connect, stated
explicitly with two attributes or child elements.

>12) "p:directory-list" :š option name="path" : "the value of the path must
be an anyURI". Why it is not names "uriPath" then?

Because anyURI can be a path, but a path can't always be URI. anyURI is an
XML Schema datatype, which is why it was chosen instead of something
"custom" like "uriPath".

>14) Namespace rename: "2. Each response header ... is translated into
c:header element". Short or long notation?

Huh? Aren't HTTP headers always a name/value pair? If so, then what this
means is "as received". If you have "Content-type:text/html;charset=utf-8",
it becomes <c:header name="Content-type" value="text/html;charset=utf-8"/>.
I'm not sure I see what you mean. Hope someone from the WG does.

Received on Tuesday, 16 October 2007 18:18:23 UTC