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

Re: position() after match in component

From: Innovimax SARL <innovimax@gmail.com>
Date: Thu, 7 Jun 2007 16:48:02 +0200
Message-ID: <546c6c1c0706070748q65415d12v4b567fc05bbdd604@mail.gmail.com>
To: "Norman Walsh" <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org

On 6/7/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / Richard Tobin <richard@inf.ed.ac.uk> was heard to say:
> | This is *NOT* about position() in document sequences.
>
> :-)
>
> | In a component like string-replace, a match pattern is applied to all
> | the nodes in a document to identify a set of nodes, and another xpath
> | expression is applied to each matching node (to determine the
> | replacement text, in the string-replace case).  The context node is
> | the matching node, but what is the rest of the context, i.e. the
> | context position and context size?  Is the context position the
> | position of the node amongst the matching nodes?  Is the context
> | position the number of matching nodes?
> |
> | It seems obvious that the answer would be "yes" if the nodes were
> | obtained from a select expression, but not so obvious given that it is
> | a match pattern.
>
> In XSLT, there's always a current node and a current node list.
>
>   <xsl:apply-templates/>
>
> is the same as
>
>   <xsl:apply-templates select="*"/>
>
> In this case, the context position/context size of the matched node is
> its position amongst its element siblings (because that's what was
> selected as the current node list).
>
> However, we want to be able to stream many of our microsteps. On that
> basis, I'd be in favor of saying that the context position and context
> size are both 1 when the replace expression is evaluated in
> p:string-replace (and in analagous situations on other steps).
>
> The other logical possibilities I see are:
>
> 1. The position among all the matching nodes.
> 2. The position of the matching node among its siblings.
>
> Both require an unbounded amount of look ahead.
>

I think like Jeni (for her position on last()) for this one :
We should give a minimum but no maximum (even if it is a nightmare for
interoperability) on what we expect
It would just be a dynamic error (or out of memory error)

May be I missed something on the complexity...

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 14:48:40 GMT

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