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

Saxonica Comment 7 on XProc last-call draft, sections 1 and 2

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 01 Oct 2007 16:54:49 -0400
To: public-xml-processing-model-comments@w3.org
Message-ID: <m2odfio8rq.fsf@nwalsh.com>
[Moving this to its own thread for easier tracking. Please follow-up
on this thread.]

/ Michael Kay <mike@saxonica.com> was heard to say:
| 7. Technical. In 2.5, Parameters, it seems unnecessarily constraining to
| require that the value of a parameter be a string. In XSLT, for example, it
| is common for a parameter to have a document as its value.

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| For V1, the WG has decided that all parameters will be exclusively
| strings. 

/ Michael Kay <mike@saxonica.com> was heard to say:
| Sounds to me like a simplification too far. Makes it quite hard to write a
| pipeline in which a transform step merges two input documents that are
| constructed by earlier stages.

/ Norman Walsh <ndw@nwalsh.com> was heard to say:
| Yes, I was personally quite surprised when consensus went that way, but
| it did. I don't think it's really a very significant limitation because
| XProc steps give you other ways of tackling the problem. The first
| that occurs to me is:
| 
|   <p:wrap-sequence>
|     <p:input port="source">
|        <p:pipe ... gets the first of two documents ... /> 
|        <p:pipe ... gets the second of two documents ... /> 
|     </p:input>
|     <p:option name="wrapper" value="wrapper"/>
|   </p:wrap-sequence>
| 
| Send the output of that step on to your transformation and
| grab the two documents from inside the "wrapper".
| 
| I'm sure that there are some things that could be done more
| conveniently with structured parameter and option values, but I think
| you'll need some pretty compelling use cases to persuade the WG to
| undertake that large a change.

/ Michael Kay <mike@saxonica.com> was heard to say:
| But this (a) means rewriting the stylesheet (perhaps quite extensively - for
| example it means that keys change their scope), and (b) almost certainly
| cannot be implemented as efficiently, especially if one of the documents
| contains lookup values that form an input to many transformations.

Received on Monday, 1 October 2007 20:55:04 GMT

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