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

Re: Slight inconvenience of using only @select for options

From: Innovimax SARL <innovimax@gmail.com>
Date: Wed, 23 Apr 2008 10:52:15 +0200
Message-ID: <546c6c1c0804230152q5b9eccc0ta1737307cc143e32@mail.gmail.com>
To: Toman_Vojtech@emc.com
Cc: public-xml-processing-model-wg@w3.org
I agree and came across this problem too

I think that the spec should clearly state that for static value for with
option, you *SHOULD* use the short form

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

But I must admit that it does not solve the problem when you want to do that
for parameter or when you just want to use non contextual XPath ("$option",
"2+2",)

Even if I'm sympathetic to your proposal (to make default binding, empty
document), it would make p:input and p:with-option asymetric, which could be
a  potential burden for users

One more argument in *favor* of your proposal is that, generally,
p:with-option would rarely be connected to the default readable port

Having said that, if no other proposal are on the table, I would go for your
proposal

Mohamed


On Wed, Apr 23, 2008 at 10:23 AM, <Toman_Vojtech@emc.com> wrote:

>
> Hi all,
>
> I just observed that the removal of the @value attribute from p:option
> makes using options a bit cumbersome in some cases.
>
> The problem can be illustrated on this (old syntax, uses the @value
> attribute) pipeline:
>
> <p:identity>
>  <p:input port="source" select="//chapter"/>
> </p:identity>
> <p:wrap-sequence>
>  <p:with-option name="wrapper" value="book"/>
> </p:insert>
>
> 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:insert>
>
> The empty binding for the "wrapper" option is necessary otherwise the
> option is bound to the default readable port (section 5.7.3) which
> produces a sequence of documents which in turn causes a dynamic error
> XD0008. In other words, the following does not work (unless p:identity
> produces exactly one document):
>
> <p:identity>
>  <p:input port="source" select="//chapter"/>
> </p:identity>
> <p:wrap-sequence>
>  <p:with-option name="wrapper" select="'book'"/>
> </p:insert>
>
>
> 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?
>
>
> Regards,
> Vojtech
>
> --
> Vojtech Toman
> Principal Software Engineer
> EMC Corporation
>
> Aert van Nesstraat 45
> 3012 CA Rotterdam
> The Netherlands
>
> Toman_Vojtech@emc.com
>
>


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Wednesday, 23 April 2008 08:52:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 23 April 2008 08:52:53 GMT