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

Re: The semantics of position() -- trying to be very explicit

From: Innovimax SARL <innovimax@gmail.com>
Date: Thu, 7 Jun 2007 09:56:39 +0200
Message-ID: <546c6c1c0706070056j2a28ab7bve375cdd6cc481b13@mail.gmail.com>
To: "Jeni Tennison" <jeni@jenitennison.com>
Cc: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

On 6/7/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> Innovimax SARL wrote:
> > Two questions :
> > 1) what about empty sequences ?
>
> In a <p:for-each> or <p:viewport>, then the body doesn't execute, so you
> never need to evaluate a position() call in this context.
>
> In a <p:option>, <p:parameter>, <p:choose> or <p:when>, I think that it
> should be a dynamic error (which MAY be reported statically) if the
> context supplied is anything but a single document.


>
> When an XPath is passed as an option to a step, then it's up to the step
> how it's evaluated. <p:matching-documents> will be like <p:for-each>,
> for example.
>
> > 2) Are we clear that "position()" cannot be evaluated in a @match ?
>
> Patterns can't contain position() except within a predicate. For
> example, match="div[1]" is a shorthand for match="div[position() = 1]",
> and will match any <div> that is the first <div> child of its parent.
>
> > and cannot be evaluated in a @select of a for-each (since this one
> > should evaluate a node set), nor in a @select of a p:input.
>
> Since these must return nodes, and there's no operator that uses
> position() to create a node, then the only way position() can appear in
> these contexts is within a predicate.
>
> > So position() could only be used in
> > * a p:when/@test
> > * a p:option/@select as a constant (position() is evaluated and then
> > concatenated for example : few useful use cases)
> > * a p:option/@value for something waiting for a boolean or a number
> > or a string after having evaluated it as XPath
> >   + option(test) in matching document (p:subsequence)
> >   + a bunch of options evaluated to number or string (few useful use cases)
> >
> > As a consequence, are we clear that using position() instead of
> > p:position(), gives us only two places where to use this construct in
> > a potentially useful manner ?
>
> You make it sound as though p:position() could be used in other
> contexts? I can't see how.

position() is dependant on the context node, right ?
so
"position()" is the position() of the context node
"div[position()=2]" is the position() of the context of the predicate
(in this case div)

if we state that p:position() is bounded to the position of the input sequence
then
"div[p:position()=2]" would select the divs of the second document in
the sequence in a for-each


that's why it is different from my perspective

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 Thursday, 7 June 2007 07:56:41 GMT

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