RE: Saxonica Comments on XProc last-call draft, sections 1 and 2

Thanks for the quick reply.
> 
> | 2. Nomenclature. "validate-xml-schema" is a misleading name 
> for a step 
> | that validates an instance.
> 
> Uhm. I suppose. I guess we could rename them 
> "validate-with-xml-schema", "validate-with-relax-ng", 
> "validate-with-schematron" if you think that would be a 
> significant improvement.

Unless you've got a standard format for step names like verb-noun, I think I
would use "xml-schema-validate", "relax-ng-validate".
> 
> | 3. Clarification. It becomes clear later, but it's 
> confusing to read 
> | in the first para of section 2 that a pipeline contains no 
> loops, and 
> | in the fourth para of 2.1 that a compound step may contain 
> (or "reconstruct") an iterator.
> 
> How about:
> 
>   [Definition: A pipeline is a set of connected steps, with outputs of
>   one step flowing into inputs of another.] A pipeline is itself a
>   step and must satisfy the constraints on steps.
> 
> And we just leave the whole loop question until later.

Fine.
> 
> 
> | 6. Clarification. In 2.2, I don't understand this: "Within 
> a compound 
> | step, the declared outputs of the step can be connected to: * The 
> | output port of some contained step. * A fixed, inline document or 
> | sequence of documents. * A document read from a URI." How can an 
> | output of a step be a document read from a URI?
> 
> Like this:
> 
>   <p:group>
>     <p:output port="out1"> ... </p:output>
>     <p:output port="out2">
>       <p:document href="someURI"/>
>     </p:output>
>   </p:group>
> 
> It seems a little silly in isolation, but recall that all of 
> the branches of a choose have to have the same outputs. In 
> the otherwise branch, you may want to dummy up some of them. 
> Having allowed a fixed, inline binding, it seems arbitrary to 
> forbid a URI binding.

I'm still confused. There's obviously something here I haven't grasped. I
thought p:output was defining the destination for something that a step
creates, and I don't see how that can be "a document read from a URI".
> 
> | 7. Technical. In 2.5, Parameters, it seems unnecessarily 
> constraining 
> | to require that the value of a parameter be a string. In XSLT, for 
> | example, it is common for a parameter to have a document as 
> its value.
> 
> For V1, the WG has decided that all parameters will be 
> exclusively strings.

Sounds to me like a simplification too far. Makes it quite hard to write a
pipeline in which a transform step merges two input documents that are
constructed by earlier stages.
> 
> | 8. Technical. By the time I get to 2.6, I'm wondering what 
> precisely 
> | the spec means by an "XML Document". An Infoset? A PSVI?
> 
> I think "an infoset" is about the best answer we could give. 
> We're trying to leave implementors the freedom to use SAX 
> events, StaX events, DOMs, or even serialized XML; whatever they want.

I agree with the objective, but I'm not sure that saying nothing is the best
way to achieve the aim. And there may be cases where the nature of the
document passed between steps needs to be specified, e.g. when passing the
output of schema validation to a schema-aware stylesheet.
> |
> | 11. Technical 2.8.1. Making the default context node an "empty 
> | document node" is probably a mistake; you would want to make the 
> | decision differently with XPath 2.0, and it will be hard to 
> change later.
> 
> What do you suggest?

Well, firstly, I think you should allow XPath 1.0 or 2.0 at implementor
discretion (with the user perhaps declaring what they are using). Then say
that it's an error to refer to the context node if there isn't one, but an
XPath 1.0 processor may use the fallback of returning an empty document.

Michael Kay
http://www.saxonica.com/

Received on Wednesday, 26 September 2007 18:39:59 UTC