Re: Slight inconvenience of using only @select for options

/ Toman_Vojtech@emc.com was heard to say:
| I just observed that the removal of the @value attribute from p:option
| makes using options a bit cumbersome in some cases.
[...]
| With the new syntax, the pipeline must be rewritten as follows:
|
| <p:identity>
|   <p:input port="source" select="//chapter"/>
| </p:identity>
| <p:wrap-sequence>
|   <p:with-option name="wrapper" select="'book'">
|     <p:empty/>
|   </p:with-option>
| </p:wrap-sequence>

I suggest instead:

 <p:identity>
   <p:input port="source" select="//chapter"/>
 </p:identity>
 <p:wrap-sequence wrapper="book"/>

[...]
| I am not saying the described behaviour is wrong, but it can be a bit
| awkward that you will have to specify p:empty binding very often to
| prevent dynamic errors. As I see it, here is a sort of a 'conflict'
| between two types of XPath expresions:
|
| - Expressions that actually query the content (for instance: //book). In
| this case, you probably want the option to be bound to the default
| readable port automatically (current behaviour)
| - Expression that do not query the content (for instance: 'true' or:
| p:system-property('p:language')). In that case, the binding does not
| matter (and can be empty).
|
| I don't know which type of XPath expressions will be more frequent in
| XProc, but since most options take simple boolean or string values,
| perhaps the sentence in 5.7.3 can be changed to something like:
|
| "If a select expression is used but no document binding is provided, an
| empty document is used as the context node."
|
| In other words, if you want to query content in your XPath expression,
| you will have to provide an explicit p:pipe, p:inline or p:document
| binding. But I am not sure whether such change would actually improve
| anything.
|
| The same applies also to variables and parameters.
|
| Any thoughts?

I think the "shortcut" options are the right answer for simple,
literal string values. For expressions that actually need to be
evaluated, I'm guessing that the implicit binding to the primary input
is the better answer.

However, I guess we could say that a sequence is an error
if-and-only-if the expression refers to the context. But I'm not
immediately in favor of that because I'm not sure how to *tell*.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Debugging is 99% complete most of the
http://nwalsh.com/            | time--Fred Brooks, jr.