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

Re: A proposal to restructure our top-level syntax

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Wed, 12 Dec 2007 17:28:44 +0000
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org
Message-ID: <f5b7ijjhlf7.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Norman Walsh writes:

> Users writing pipeline libraries will have to learn about this
> declaration dance, but maybe they're already more sophisticated.
>
> It will allow pipeline authors to modularize their pipelines "inline".
>
> Migrating the inlined pipelines into external libraries will be
> straightforward.
>
> But...
>
> | 1) Add optional subpipeline content to p:declare-step -- if it's
> |    present, it's the definition:
> | 
> | <p:declare-step
> |   type = QName>
> |     (p:input |
> |      p:output |
> |      p:option)*
> |      _subpipeline_
> | </p:declare-step>
>
> That's not really a subpipeline is it? It's a p:pipeline, no? If it's
> a subpipeline then declare-step has to have a name so that the steps in
> the subpipeline can refer to the declared ports. Or...what am I missing?

Given the proposed interpretation of p:pipeline, we should change the
proposed shorthand interpretation of <p:pipe port="xxx"/> to always
give you the lexically enclosing p:declare-step.

>   <p:declare-step type="px:xslt10">
>     <p:input port="source" primary="true"/>
>     <p:input port="stylesheet"/>
>     <p:output port="result"/>
>
>     <p:xslt version="1.0">
        <p:input>
         <p:pipe port="stylesheet"/>
        </p:input>
>     </p:xslt>
>   </p:declare-step>
>
> | 5) Change the definition of p:pipe so that 'step' is optional, and if
> |    omitted means the lexically inclosing p:pipeline.
>
> This seems orthogonal. And if we're goint to reopen discussion of
> making step and/or port optional on p:pipe, I have a different
> proposal :-)

It's crucially _not_ orthogonal, it's necessary!

> | I don't think Norm's other objection to my original 'require I/O decls
> | only on libraries' proposal is as strong now -- to publish a pipeline,
> | I just rename it to p:declare-step and wrap it in a
> | p:pipeline-library, probably adding I/O declarations as well.  No
> | internal changes are required.
>
> Can I have a pipeline document that has p:declare-step as it's root
> element? Can I import that directly?

Could do.  Your previous message is relevant.  Let me think about this
a bit.

> | This also simplifies things in that p:import now _only_ imports
> | libraries.  It will of course still be possible for an implementation
> | to 'run' a library, defaulting to the first or only p:declare-step in
> | the absence of a type argument.
>
> We rejected a proposal to add an attribute to p:pipeline-library to
> indicate the "default" pipeline to run. Did we decide that "the
> first" was the default?

I don't think we decided. . .

> | One final note -- (1) above arguably oversimplifies, and so makes my
> | assertion about how you publish a pipeline false, because as written
> | it doesn't allow some things that p:pipeline does in its content.  I
> | think on balance I'd prefer to be catholic about that, and so we should
> | rather have
> |
> | <p:declare-step
> |   type = QName>
> |     (p:input |
> |      p:output |
> |      p:import |
> |      p:declare-step |
> |      p:serialization |
> |      p:option)*
> |      _subpipeline_
> | </p:declare-step>
>
> That's not really a subpipeline is it? It's a p:pipeline, no? If it's
> a subpipeline then declare-step has to have a name so that the steps in
> the subpipeline can refer to the declared ports.

See above.

> | with the stipulation that a) nested declarations and imports are _not_
> | visible higher up; b) serialization is only relevant if the step is
> | 'run'.  Which points out another collateral benefit -- p:serialization
> | really belongs on p:declare-step, because its perfectly coherent to
> | ask an implementation to 'run' a step from a pipeline library w/o
> | knowing or caring whether it's declared built-in or user-defined,
> | that is, without or with an explicit subpipeline.
>
> Interesting. This seems to shift the ground a fair bit. Consider:
>
> <p:declare-step type="px:xslt-to-html">
>   <p:input port="source" sequence="true" primary="true"/>
>   <p:input port="stylesheet"/>
>   <p:input port="parameters" kind="parameter" sequence="true"/>
>   <p:output port="result" primary="true"/>
>   <p:output port="secondary" sequence="true"/>
>   <p:option name="initial-mode"/>
>   <p:option name="template-name"/>
>   <p:option name="output-base-uri"/>
>   <p:option name="version"/>
>   <p:serialization method="html" port="result"/>
>   <p:xslt>
>     ...however we resolved the binding questions above...
>   </p:xslt>
> </p:declare-step>
>
> Now I can call px:xslt-to-html directly? And if I call it directly then
> it uses the serialization options I provided? Can I call p:xslt directly,
> without a pipeline wrapper? If not, why not?

Sounds OK to me. . .

> | Thanks for listening :-)
>
> Finally, I think the inability to import two simple pipelines (because
> of the name clash) is a critical problem. I can think of some ways
> around it, such as allowing href on p:declare-step, but...it makes thinks
> a little more complex.

As I said, I'm thinking about that. . .

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHYBpMkjnJixAXWBoRAq3JAJ419VPmLKt0Iub0PZT+GGEHTv7KawCfZz3+
b201yJdM75Y3dfICUklJk8o=
=Gz5x
-----END PGP SIGNATURE-----
Received on Wednesday, 12 December 2007 17:28:57 GMT

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