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

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

From: Norman Walsh <ndw@nwalsh.com>
Date: Wed, 26 Sep 2007 13:59:25 -0400
To: Michael Kay <mike@saxonica.com>
Cc: public-xml-processing-model-comments@w3.org
Message-ID: <m23ax1tiiq.fsf@nwalsh.com>
/ Michael Kay <mike@saxonica.com> was heard to say:
| 1. Technical (but non-normative). Fig 1 Example. Since the example is trying
| to illustrate that a pipeline takes XML documents as input, it would be
| better if the input consisted of "schema documents" rather than "schemas".
| (A schema document is an XML document, a schema is not). 

Fair enough; I think we could change the labels in the diagram to
read "source document", "schema documents", and "result document".

| 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.

| 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.

| 4. Clarification. In 2.1 it's hard to reconcile the definition [Definition:
| The steps (and the connections between them) within a compound step form a
| subpipeline.] with the next sentence "A compound step can contain one or
| more subpipelines". If the steps form one subpipeline then how can the
| compound step contain many subpipelines? Are we talking about transitive
| containment here?

Yeah, that's a little clumsy; I'll give that some thought.

| 5. Clarification. At the end of 2.1, "A step can have zero parameter input
| ports, and each parameter port can have zero parameters passed on it." it
| might be clearer to say "A step can have zero, one, or many parameter input
| ports, and each parameter port can have zero or one parameters passed on
| it.".

Yes, I think that's an improvement; thanks.

| 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.

| 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. 

| 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.

| 9. Technical. In 2.7, the Environment is defined as containing static
| information. And it includes options. But I don't think it's true that the
| values of the options are known statically, is it?

Good point. I'll have to look at that.

| 10. Typo. In 2.8 para 4, "step step".
|
| 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?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Education's purpose is to replace an
http://nwalsh.com/            | empty mind with an open one.--Malcolm
                              | Forbes

Received on Wednesday, 26 September 2007 17:59:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:42 GMT