Re: Viewport and nested selected nodes

Jeni Tennison wrote:
> 
> Hi,
> 
> Alex Milowski wrote:
> 
>> So, in XSLT, a select attribute with a value of "//h:div" would return
>> all the "h:div" elements in the document.  In our case, we're going
>> to return only the outermost elements.  As such, it isn't the same thing
>> as a select pattern in XSLT.  Given that, it seems like we're going
>> to confuse users who come from XSLT-land.
> 
> 
> There's no such thing as a "select pattern" in XSLT; in XSLT, a 'select' 
> attribute always holds an XPath expression, and 'match' is the usual 
> attribute for an XSLT pattern.

I'm just using the name that was used earlier in this thread.

> 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>

That use of 'select' is completely inconsistent with the use
described for 'viewport'.

> The 'select' for viewport doesn't behave in the same way as it does with 
> computed ports (and for-each) -- it only identifies outermost nodes -- 
> and therefore should be called something different from the 'select' for 
> computed ports. (This is part of my argument about putting these 
> attributes on the <p:viewport> rather than on a <p:input> inside.)

I disagree.  I think they need to work the same way.  This introduces
language complexity for the user and implementor.

Also, this particular use case is very easy to do right now without XML
pipelines in XSLT (e.g. apply a transform to each section in a single
document).  While we have many examples that could be implement in
other ways, this particular one strikes me as bending the pipeline
language.  ...but that's my opinion... :)

>> Note that a match pattern doesn't suffer from that confusion because
>> the "apply" semantics will be very similar to XSLT's template matching.
> 
> 
> But you *select* the nodes to which to apply templates using an XPath 
> expression. The match pattern on a template just helps you decide which 
> template to use to process them. We don't have a template-matching model 
> for processing different kinds of nodes in XProc, so I don't think that 
> the XSLT model applies.

The match pattern is a subset of XPath so that they can be compile into
a "matching" construct which reverses the question to "does this node"
match.  In the case of any computed port--whether for viewports or any
random port--an implementation needs to compute from the incoming
document a set of *matching* elements.  As such, the analogy works.

It would be very easy for an XSLT implementor to implement match
patterns for computed ports.  In fact, with a few extension functions,
they could probably implement the whole language...

If they aren't match pattern--but full XPath expressions--no 
off-the-shelf XPath implementation is going to be able to handle "the 
outermost" without additional processing.

-- 
--Alex Milowski

"The excellence of grammar as a guide is proportional to the paucity
of the inflexions, i.e. to the degree of analysis effected by the
language considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 26 October 2006 00:28:52 UTC