Re: Comments on Editor's Draft 9 January 2008

/ Toman_Vojtech@emc.com was heard to say:
| 1. Section 4.7.1 (options). From the schema (rng) it looks like the
| shortcut form can only be used for atomic steps and "other" compound
| steps. Why isn't it possible to use the shortcut form also on built-in
| compound steps (such as for-each or group) which can specify options in
| the "long" form?

I think the shortcut form only makes sense on atomic steps where
there's a declaration for the option. On compound steps, allowing the
shortcut form would be both a declaration and a binding and so there'd
be no way to tell if there was a typo or something.

I removed it from "other" compound steps.

| 2. Because of the changes in the way the steps/pipelines are declared,
| the step declaration can now contain logs or serializations. For
| pipelines this is fine, but is it OK to declare logs/serializations for
| atomic steps? If so, the specification should mention this and it should
| also define how the logs/serializations can be used on atomic steps (for
| instance, only declared logs/serializations can be used; the declared
| logs/serializations will be used unless overriden in the "invocation";
| etc.)

Right, those only make sense if the atomic step is evaluated directly
by the XProc processor. They should be ignored if the step appears
inside a pipeline.

I added that.

| 3. p:xquery step: I wonder if the XPath extension functions
| (p:system-property(), p:iteration-position() etc) shouldn't also be
| available the p:xquery step?

Those functions aren't available inside any atomic steps. They can be 
used to compute the values of parameters for the XQuery step, of course.

| Also, I assume that the parameters that appear on the parameter input of
| the p:xquery step should be used for setting values of XQuery external
| variables. However, the specification of the p:xquery step does not
| mention this.

Alex, can you take a look at this, please?

| 4. Section 4.3 (p:viewport). I think the description of the match
| expression should say that the expression cannot match an attribute
| node. Or does viewport support replacing of attributes?

It should forbid them. Fixed.

| 5.Section 4.1 (p:pipeline): "All p:pipeline pipelines have an implicit
| primary input port named "source' and an implicit primary output port
| named "result". Any input or output ports that the p:pipeline declares
| explicitly are in addition to those ports and may not be declared
| primary."
|
| So, is it allowed to explicitly specify the implicit input/output ports
| inside p:pipeline? If so, is it possible to redefine their properties
| (primary, sequence)? Is the following permitted?
|
| <p:pipeline>
|   <p:input port="source" sequence="false"/>
|   <p:output port="result" primary="false"/>
|   <p:output port="result2" primary="true"/>
|   ...
| </p:pipeline>

No. The implicit declarations of source/result cannot be repeated or
changed. Of course, you can use p:declare-step if you want to have
different values.

| 6. Section 4.1 (p:pipeline). Pipelines can no longer specify the "name"
| attribute. How does that work together with section 3.2 (Scoping of
| Names). Is the sentence "All the step types in a pipeline must have
| unique names: it is a static error (err:XS0036) if any step type name is
| built-in and/or declared or defined more than once in the same scope."
| still valid?

Yes, the local name of the type attribute functions as the name of a
p:pipeline.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Always do one thing less than you think
http://nwalsh.com/            | you can do.--Bernard Baruch