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

Re: Option syntax

From: Innovimax SARL <innovimax@gmail.com>
Date: Sat, 2 Jun 2007 00:12:44 +0200
Message-ID: <546c6c1c0706011512u9e25364u31b1de39579edd28@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org

On 5/31/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> [...]
> | I understand the argument that it'd be a pain for implementers to
> | provide context to all XPath expressions while still providing
> | efficient applications, but given a choice between least surprise to
> | users and least work to implementers, I'm going to opt for the former.
> | In all other cases (eg <p:for-each>, <p:viewport>, <p:choose>), we say
> | that the default readable port provides the context if one isn't
> | specified explicitly.
>
> Yes. I've never thought of options in these terms, but I concede that
> the principle of least surprise applies.
>
> | In the case of <p:choose> (where you also have
> | to evaluate an XPath expression), it's a dynamic error if the default
> | readable port gives a sequence: if you prefer that rule to picking the
> | first document, I'd be happy with that.
>
> Yes, I like that better.
>

Hum...interesting

It just recall me that I would never be able to make something like this
<p:choose>
  <p:when test="....is the input a sequence...">
  </p:when>
</p:choose>

I would propose a p:occurence component, that will do something like
p:count but only give 3 possible answers : 0, 1, + (so will need small
buffering)

Mohamed
-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Friday, 1 June 2007 22:12:48 GMT

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