Re: Comments on Editor's Draft 9 January 2008

Hi Toman,

I'm trying to catch up on a few things that I think remain unanswered.

/ Toman_Vojtech@emc.com was heard to say:
[...]
| 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.)

I believe we've addressed this:

   If p:log or p:serialization elements appear in the declaration of
   an atomic step, they will only be used if the atomic step is
   directly evaluated by the processor. They are ignored if the step
   appears in a pipeline.

| 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 in any step. They're only available
to the processor for computing paramters.

I think it would be a pretty significant implementation burden to make
the be a required part of the XQuery (or any other step). Better, I
think, for the user to pass them in as parameters if they're needed by
a particular query.

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

Yes, I think that's the intent. Alex, could you clarify the p:xquery step?

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

Fixed, I believe.

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

I believe we've rectified this by making it an error to import a
pipeline that does not define a type.

                                        Be seeing you,
                                          norm

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