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

Re: Issue #3306

From: Innovimax SARL <innovimax@gmail.com>
Date: Sun, 4 Jun 2006 19:40:41 +0200
Message-ID: <546c6c1c0606041040n23a7d8d4x35c8bc995a34082@mail.gmail.com>
To: "Erik Bruchez" <ebruchez@orbeon.com>
Cc: public-xml-processing-model-wg@w3.org
Hello Eric,

This is exactly the proposal of Richard at last telcon
But the problem is that NODESETs are SETs
Even if the specification speeks about beeing *consistent*, i'm not sure we
have the same behavior for set as for sequence

What about the behavior if we have two identical documents in the sequence
for example ?

I'm inclined to think that NODESETs are "not too far" from NODELIST or
DOCUMENT SEQUENCE but, it is clear for me that if we use NODELIST, we
introduce a new type in XPath 1.0 and as a consequence, implementors won't
be able too just reuse existing XPath 1.0 component, even XPath
2.0component, but to hack them.

This having been said, if we have to use a hacked XPath in XProc, let's look
at all extension we could have to put in to have a nice construct

My point of vue at the beginning was that XProc 1.0 had to be buildable from
existing part that had to be XPath 1.0 like, letting to V.next the need to
hack existing building parts

If we assume now, that an XPath 1.0 without hack is not sufficient, i'm
inclined to add more feature in XProc 1.0 that i previously had put in
V.next

Cheers

Mohamed






On 6/2/06, Erik Bruchez <ebruchez@orbeon.com> wrote:
>
>
> All,
>
> Regarding this issue:
>
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=3306>
>
> I think it is worth noting that XSLT 1.0 already discusses the
> possibility of node-sets spanning multiple documents:
>
>    http://www.w3.org/TR/xslt#document
>
> XSLT 2.0 updates this as well, using sequences of course:
>
>    http://www.w3.org/TR/xslt20/#document
>
> The document() function is allowed to take a node-set as first
> argument, which basically identifies a bunch or URIs. The result of
> the document() function in this case is a node-set which may contain
> nodes from different documents (typically, one node per document, and
> even more typically, each document's root node).
>
> (With XSLT, order of nodes among documents is implementation-dependent
> but has to be "consistent".)
>
> It is possible to have a variable refer to that node-set, of course:
>
>    <xsl:variable name="my-nodes" select="document(//my-uris)"/>
>
> Now again my point doesn't regard the document() function, which we
> don't have in XPath, but the fact that the notion of having node-sets
> containing nodes from multiple documents is not new, and that we can
> be consistent with what is being done in XSLT 1.0.
>
> In XProc, we wouldn't have something really different if we had
> $documents refers to a "sequence" of documents. Make $documents a
> node-set containing the root nodes of the documents in the order in
> which they "arrive". Jeni can then write her:
>
>     <p:choose>
>       <p:input name="input" select="$documents" />
>       <p:when test="count($input) >= 1">
>         ...
>       </p:when>
>       <p:otherwise>
>         ...
>       </p:otherwise>
>     </p:choose>
>
> This sounds like a simple and compelling solution to me.
>
> -Erik
>
> --
> Orbeon - XForms Everywhere:
> http://www.orbeon.com/blog/
>
>


-- 
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 Sunday, 4 June 2006 17:40:51 GMT

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