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

Re: Comments on Editor's Draft 9 January 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 08 Feb 2008 12:10:36 -0500
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2hcgjl6gj.fsf@nwalsh.com>
/ Toman_Vojtech@emc.com was heard to say:
|> / 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.
| But isn't it the same also with the long option form? I mean, it is also
| a declaration and a binding.

Yes. We could make

  <p:group px:some-random-attribute="value" ...>

be the same as

  <p:group ...>
    <p:option name="px:some-random-attribute" value="value"/>

but it would never be possible to detect errors because there's no
declaration against which to compare the short form. Given that we
don't think options on compound steps are going to be very common,
we're being conservative and not allowing the short form.

|> | 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.
| Now I am really confused. Does the specification mention this
| possibility (declaring a pipeline with different primary input/output
| properties)?

I think so. The intent is that if you use the p:declare-step form, then
you can declare any inputs and outputs you like for a pipeline. If you
use the shortcut form, p:pipeline, then you get exactly one input and
exactly one output. You can add additional non-primary inputs and outputs,
but you can't change the primary "source" and "result".

Maybe it would be cleaner if we didn't allow you to add others.

Cleanest of all would be to remove the p:pipeline altogether, but I
think that would be awkward.

| I also thought it was not possible to declare different names than
| "source" and "result" for primary pipeline input/output ports in
| p:declare-step (the "source" and "result" strings seem to be quite
| hard-coded in section 4.1 - p:pipeline), but after reading section 5.8.2
| (declaring pipelines) again, I am not that sure any more. It looks to me
| now that I am free to declare any primary input/output ports on a
| pipeline...

If you use the declare-step form, you're free to do anything you like.

The constraints on source/result only apply to the syntactic sugar
"p:pipeline" form.

Is that any clearer?

                                        Be seeing you,

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

Received on Friday, 8 February 2008 17:10:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:25 UTC