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

Re: Viewport and nested selected nodes

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 26 Oct 2006 10:02:57 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87u01rcgz2.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| The 'select' for computed ports (and the input for for-each *is* a computed
| port) must identify all nodes in the document, not just the outermost ones. My
| use case is creating multi-page HTML output in which every section (including
| sections-within-sections) has a separate page. I want to do this with:
|
|   <p:for-each>
|     <p:input port="section" ... select="//section" />
|     <p:output port="result" step="toHTML" source="result" />
|     <p:step name="toHTML" type="p:xslt">
|       <p:input port="document" source="section" />
|       <p:input port="stylesheet" href="section2html.xsl" />
|     </p:step>
|   </p:for-each>

If you expect not only the outer sections but also the inner sections
to be selected, how do you imagine that this works? Consider:

<section id="s1">
  <p/>
</section>
<section id="s2">
  <p/>
  <section id="s2.1">
    <p/>
  </section>
</section>

In the first iteration, the XSLT process gets

  <section id="s1">
    <p/>
  </section>

as input. In the second iteratio, what does it get?

<section id="s2">
  <p/>
  <section id="s2.1">
    <p/>
  </section>
</section>

or

<section id="s2">
  <p/>
</section>

If it gets the former, then in the third iteration, it's going to
process the s2.1 section *again* which isn't likely to be what users
expect. It sure isn't what I'd expect.

If it gets the latter, *how* does that work? Is the for-each step
expected to extract out nested sections and hold them in abeyance?
In this case, the nested section is at the end, but that's not going
to be the general case.

I expect for-each and viewport (and actually, maybe all select
expressions in XProc) to select only the highest level matching
subtrees.

If this means the attribute has to be renamed, I suppose I can live
with that, though I'm not personally disturbed by the additional
semantic.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Thursday, 26 October 2006 14:03:23 GMT

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