Re: Questions + comments on XProc WD 14 December 2007

/ Toman_Vojtech@emc.com was heard to say:
| 1. Is there any use for the "name" attribute on p:pipeline-library? If
| so, what can it be
| used for?

It's gone now :-)

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

Overtaken by events, I believe.

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

I think this has also been overtaken by events.

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

Yeah, I think that statement was probably causing more confusion than
help.

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

No, the implicit binding is explicitly based on document order.

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

I think this has also been overtaken by events.

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

Right.

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

They all get bound to the last step in the subpipeline.

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

Input ports must have bindings. An unbound output port is never read
so it's not clear what it means for it to produce anything.

| 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)?

Yes, I think so. I created another thread for that question.

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

Yes, that will be "the same binding".

| 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?)

Oh, those need to be dynamic errors, I think. Fixed.

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

Yes.

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

You don't think it's sufficient to have slightly different messages in
the two cases?

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

Fixed.

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

I think that's been fixed. At least, I can't find it now.

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

The manufactured binding for a non-primary parameter input port is to an
empty sequence of documents, so the order doesn't matter.

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

Hmm. It's an error to put primary or sequence on an input binding, but
I guess it's err:XS0008.

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

Yes.

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

This isn't legal. The stylesheet port isn't a primary input port and
therefore does not get a binding automatically.

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

Bleh. I think you might be right about it being confusing.

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

Yep.

| 21. xproc.rng: The type OtherAtomicStep can contain only p:input - why
| not also p:output?

Because you can't put p:output elements in Atomic steps. Actually, the
current schema is buggy in that respect for the standard atomic steps.

| Also, what does the declaration of StandardStep look like?

That's in steps.rn[cg].

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.