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

Questions + comments on XProc WD 14 December 2007

From: <Toman_Vojtech@emc.com>
Date: Thu, 20 Dec 2007 10:59:44 -0500
Message-ID: <6E216CCE0679B5489A61125D0EFEC78709052F7B@CORPUSMX10A.corp.emc.com>
To: <public-xml-processing-model-comments@w3.org>

Hi all,

I have a couple of questions and comments related to the latest WD:

1. Is there any use for the "name" attribute on p:pipeline-library? If
so, what can it be
used for?

2. How should an XProc processor behave if it encounters a pipeline
library without the
"namespace" attribute and the library contains pipelines (or steps) with
name but no type
information? Does empty (or unspecified) "namespace" attribute mean that
all untyped
declaration will be in no namespace? Or the XProc namespace? Or, if the
"namespace"
attribute is used, can it be empty at all? Section 5.8 says that a step
declaration cannot
be in XProc namespace unless it is a standard step. I guess that it
should not be possible
to put pipelines in the XProc namespace as well.

3. The spec allows recursive invocations of pipelines. Is the following
example valid
(only name specified, no type informationprovided)?

<p:pipeline name="test"> <test>...</test> </p:pipeline>

Or do I have to use the "type" attribute here?

<p:pipeline type="test:mypipeline" xmlns:test="http://www.test.com">
 <test:mypipeline>...</test:mypipeline> </p:pipeline>

I think the spec is not very clear on this topic.

4. Section 4.5 says: "The result of a p:group is the result of its
subpipeline."

Does this mean the result of the last step in the subpipeline? What if
the last step has
no primary output? How does this combine with specifying explicit
p:output elements on
p:group?

5. Section 2.7 says: "If there is a preceding sibling step element: If
that preceding
sibling has a primary output port, then that output port becomes the
default readable
port."

Shouldn't this be rewritten so that it takes ordering of the steps based
on the bindings
into account?

6. Section 5.1.1 says: "On p:declare-step, the p:input simply declares
the input port. It
is a static error (err:XS0042) if the declaration of a document input
port inside a
p:declare-step. Document input port declarations must be empty unless
they are declaring
and binding an input port for a p:pipeline."?

How does the following text (section 5.1.1) combine with the ability to
provide default
bindings on p:input?  Shouldn't the text be updated? Also, the message
for error XS0042 is
not really clear. I also think that the following sentence: "Document
input port
declarations must be empty unless they are declaring and binding an
input port for a
p:pipeline." should be updated: "Document input port declarations must
be empty unless
they are declaring and binding an input port for a p:pipeline OR A
COMPOUND STEP."

7. I guess the following should not be allowed (providing binding for an
output of a
standard step):

   ...
   <p:identity> 
     <p:output port="result">
       <p:empty/> <!-- or any other type of binding -->
     </p:output>
   </p:identity>
   ...

8. Section 5.4: "On compound steps, the declaration may be accompanied
by a binding for
the output."

How is the XProc processor supposed to react if I have a compound step
with multiple
p:output elements, all without a binding?

9. Input/output ports with sequence="true". If no binding exists for
such ports, should
they "return" an empty sequence of documents when accessed?

10. For-each steps that get executed zero times. Norman Walsch responded
to my (private)
e-mail with the following:

> | 5.2 What should be on the output ports of a p:for-each if the body
is evaluated zero
> | times (empty loop sequence)?
> > Each should have zero documents on it.

Just to be sure: does this apply also to output ports with "static"
bindings
(e.g. document or inline binding)?

11. Section 5.7.3 (p:namespaces), item 2: "If the element attribute is
specified, it must
contain an XPath expression which identifies a single element node (the
input binding for
this expression is the same as the binding for the p:option or
p:parameter which contains
it). The in-scope namespaces of that node are used; The expression is
evaluated in the
appropriate context, See Section 2.8, 'XPaths in XProc'."

What if the owner option/parameter does not specify any binding? Should
the implicit
readable port of the owner step be used?

12. Section 5.7.3 (p:namespaces): items 2 and 3 contain MUST - what if
the requirements
are not satisfied? When an element expression is used, what if it does
not evaluate to an
element? (fallback to default in-scope namespaces instead of using the
element's in-scope
namespaces?)

13. Section 5.7.3 (p:namespaces) - what if a sequence of documents
appears on the input of
the select expression? Should err:XD0008 be reported as in the case of
p:option?

14. The text for dynamic error err:XD0014 should be more generic so it
is meaningful both
for c:parameter and c:parameter-set

15. err:XS0035 mixes two cases together: declaration of parameter inputs
cannot contain
bindings + the owner pipeline has no primary parameter input port

16. err:XS0043 - is this really a correct error code if a pipe binding
is found in an
input declaration?

17. Section 5.1.2: When are the "manufactured" bindings for non-primary
parameter inputs
supposed to be evaluated? Last among the other parameters, similar to
the primary parametr
input port? I think the text should be relaxed a bit so it covers also
non-primary
parameter inputs.

18. What if the primary/sequence/... attributes in an input binding do
not match the
values specified in the input declaration? Do these cases all fall under
err:XS0010?

19. Section 5.1.1 (p:input, atomic step): "If no binding is provided,
the input will be
bound to the default readable port."

Does this mean that if I don't specify any bindings for (non-primary)
inputs on the step,
they all will be bound to the default readable port? (That is, both the
primary input port
and all the other non-primary input ports will be bound to the same
readable port) On an
atomic step, is there a difference between specifying an input with no
binding (empty
p:input element) and not specifying the input at all? Are the two
following invocations of
the p:xslt step equal?

<!-- first -->
<p:xslt>
  <p:input port="stylesheet"/>
</p:xslt>

<!-- second -->
<p:xslt>
</p:xslt>

I am a bit confused about this. Section 2.2 says that the step matches
if it *specifies*
all declared inputs, so my understanding is that I really have to
specify the inputs
(except maybe for the primary inputs which will be "added" automatically
by the XProc
interpreter), but no bindings are necessary.

20. Section 2.5 says: "Additionally, if a p:pipeline does not declare
any parameter input
ports, but contains a step which has a primary parameter input port...".
I think this
sentence should be changed to: "Additionally, if a p:pipeline does not
declare any
parameter input ports, but contains a step which has a primary parameter
input port WITH
NO BINDINGS..."

21. xproc.rng: The type OtherAtomicStep can contain only p:input - why
not also p:output?
Also, what does the declaration of StandardStep look like?

--
Vojtech Toman
Principal Software Engineer
EMC Corporation

Aert van Nesstraat 45
3012 CA Rotterdam
The Netherlands

Toman_Vojtech@emc.com
Received on Thursday, 20 December 2007 15:57:15 GMT

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