Re: Kinds of iteration

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I thought I'd try to summarize the different kinds of iteration that
| we've discussed.
|
| 1. Iteration over a sequence of elements...

I don't know if I want to be able to iterate over attributes, but I'd
like to be able to iterate over document, element, text, comment, and
PI nodes, I think.

|    1.a. ...identified via an XPath expression (selected from one or
|            more documents)

This is the "iterate over those things" case, right? Do stage1, stage2,
and stage3, for each of the things selected:

  <xproc:for-each select="some-expression-that-selects-nodes">
     <xproc:stage1/>
     <xproc:stage2/>
     <xproc:stage3/>
  </xproc:for-each>

I guess the output from this construct is itself a sequence of nodes.

|    1.b. ...identified via an (XSLT) pattern (all elements matching the
|            pattern within one or more documents)

How is this one different in the pipeline case? And can it be implemented
by having a component that does the pattern matching? For example, imagine
that xproc:find-patterns takes some input and produces as output a sequence
of nodes that match the selected patterns:

  <xproc:find-patterns>
    <xproc:select pattern="some-xslt-like-match-pattern"/>
  </xproc:find-patterns>

Then if you want to iterate over those you can xproc:for-each over the
output from that component. Or have I missed the point in some
fundamental way?

| 2. Iteration over a sequence of documents...

I think I concur with Richard. I'd like to see this as just a special case
of iterating over nodes.

|    2.a. ...generated by an upstream process, such as an XQuery whose
|            result is a sequence of document nodes

If a component can produce a sequence of nodes, this is straightforward.

|    2.b. ...identified within an XML document, such as an index that
|            lists the URLs of other XML documents

So this could be implemented with a component that identified the terms
in the index and returned the sequence of nodes.

|    2.c. ...created as new documents with document elements identified
|            via 1 above

I'm not sure how the XPath expressoin can create new documents...

| Some thoughts:
|
| The distinction between 1 and 2.c is important because the context of
| the element is lost when you copy an element into a new document: both
| its ancestors and its base URI are different. XSLT expects an "initial
| context node", which can be any node kind, not only a document (and
| not only an element), and given that XSLT is one of the main kinds of
| component we probably want to support that (in the Processing Model if
| not the Processing Language).
|
| If we support 2.a, we don't necessarily have to have a construct in
| the Processing Language for 2.b or 2.c: it's easy to write a process
| (in XQuery or XSLT, for example) that does 2.b or 2.c. (Again, we have
| the tension between putting control structures in the pipeline
| language and putting them into the processes themselves.)

Yep.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.