Re: Language construct syntax

Hi,

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> [...]
> | <viewport from="pipe!document" select="/doc/xsl:stylesheet"
> |           subtrees="/xsl:stylesheet/xsl:template">
> 
> I'm confused about why both select and subtrees are required. I
> thought the semantic of viewport was that it accepted a single
> document and it processed that entire document. So I'd have thought it
> could be reduced to:
> 
> <viewport from="pipe!document" select="/xsl:stylesheet/xsl:template">
> 
> What am I forgetting?

The result of mine is a <xsl:stylesheet> document. The result of yours 
is a <doc> document.

I had always envisaged the 'select' attribute as a shorthand for a 
'p:select' step.

Imagine, for a moment, that we didn't have a 'select' attribute 
anywhere, just a 'p:select' built-in step type that would create a new 
document sequence from an existing document sequence plus an XPath 
expression (or XSLT pattern, I'm not bothered), by creating a new 
document for each of the elements identified by the path/pattern.

For-each would work perfectly adequately: it would iterate over the 
documents in the document sequence you passed it, and perform its 
subpipeline on each document. When you wanted to iterate over 
subelements, you would use a p:select step to create the sequence of 
documents containing those subelements, and iterate over that:

  <p:step name="collect-sections" type="p:select">
    <p:input port="documents" ... />
    <p:param name="xpath" value="//section" />
  </p:step>
  <p:for-each>
    <p:input port="document" step="collect-sections" source="result" />
    ...
  </p:for-each>

But to make viewport work, however, you would have to have an attribute 
that held an XPath expression (or XSLT pattern, I'm not bothered) that 
indicated which elements were replaced with the result of processing 
them using the subpipeline. Let's call this 'subtrees'. It might look like:

  <p:viewport subtrees="//section">
    <p:input port="documents" ... />
    ...
  </p:viewport>

We could say that viewport can only work on one document, but there's no 
technical reason I can see to make that restriction. It's logical that 
when the input to a viewport construct is a sequence of documents, each 
of the documents in that sequence is processed such that the elements 
identified by the 'subtrees' attribute are replaced by the result of 
processing them using the subpipeline. The result is a sequence of 
documents that have been processed in such a way.

(In fact, perhaps things would be cleaner if we removed the 'select' and 
'href' attributes from the long syntax -- they're just shorthands for 
using two of the most common step types, p:select and p:load, but having 
them in the long syntax makes it more complicated and harder to see 
what's really going on.)

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 27 October 2006 09:01:57 UTC