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

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