Re: [xml-dev] Tag libraries in XSLT / XQuery?

[Michael Kay <mike@saxonica.com>]

  I think part of what you are proposing is something that retains the 
flavour of XSLT simplified stylesheets, but removes many of the 
restrictions; for example it might be simplified stylesheets plus the 
ability to import a function (or template?) library. XSLT simplified 
stylesheets never took off, probably because they are too simple. 
Enhancing them without going all the way to full XSLT would be tricky, 
because it's hard to find the right sweet spot.

The other part of your proposal is perhaps some kind of standardized 
facility for defining XSLT extension instructions - another XSLT feature 
that has never really taken off. It wouldn't be difficult to provide 
some way of mapping the user syntax

<m:graph x0="0" x1="100" f="my:x-squared#1"/>

to the underlying semantics of

<xsl:call-template name="m:graph">
<xsl:with-param name="x0" select="0"/>
<xsl:with-param name="x1" select="100"/>
<xsl:with-param name="f" select="my:x-squared#1"/>
</xsl:call-template>

(Or you could make the attributes AVTs rather than XPath expressions - 
it's not obvious which would be best).

XSLT 2.0 chose not to go in this direction, focusing instead on a 
concise function call syntax for use in XPath expressions. But it might 
still have validity, and find favour with a different audience. Try 
doing a preprocessor, and see whether people like it.

Michael Kay
Saxonica


On 23/08/2010 02:03, Erik Hennum wrote:
> Speculative XML Savants:
>
> I'm wondering whether a moral equivalent to JSP tag libraries [1] would
> be a useful addition to the XSLT / XQuery portfolio -- so that XML
> documents could use tags
>
> *  defined in an XSLT / XQuery module (instead of a Java class), and
> *  executed by an XSLT / XQuery processor (instead of a JSP container).
>
> The rationale for tag libraries (probably summarizing the familiar) is
> to establish a division of responsibility and collaboration between
>
> *  application developers who understand data access and manipulation, and
> *  page designers who understand visual layout and style.
>
> For an example, let's say an application developer creates a tag library
> with an query:people tag that queries attendee records by year and sorts
> the result list by first or last name.
>
> A page designer could then create an XHTML page with the query:people tag:
>
> <table class="attendees">
>    <tr><th>Last Name</th>
>      <th>First Name</th></tr>
> <query:people select-year="2010" sort-by="last-name">
>    <tr><td class="lname">{ $last-name  },</td>
>      <td class="fname">{ $first-name }</td></tr></query:people>
> </table>
>
> When supplied with the tag page and the tag library, a processor would
> generate an XHTML output page similar to the following:
>
> <table class="attendees">
>    <tr><th>Last Name</th>
>      <th>First Name</th></tr>
> <!-- query:people select-year="2010" sort-by="last-name" -->
>    <tr><td class="lname">Crawford,</td>
>      <td class="fname">Randy</td></tr>
>    <tr><td class="lname">Franklin,</td>
>      <td class="fname">Aretha</td></tr>
>    <tr><td class="lname">Green,</td>
>      <td class="fname">Albert</td></tr><!-- /query:people -->
> </table>
>
> Some potential scenarios for tags in XML processing environments:
>
> *  An XQuery tag library could provide views on an XML store for
>     integration and branding by HTML pages.
>
> *  An XSLT tag library could transform articles into content sequences
>     for layout as flows by XSL-FO book masters.
>
> XSLT Simplified Stylesheet Modules [2] already have several of the
> constructs needed for XML tag pages.  The legal XSLT statements include
> equivalents (such as xsl:for-each and xsl:if) for important core JSTL
> statements.  XSLT Attribute Value Templates [3] offer a parallel to the
> EL expression language.
>
> Simplified Stylesheet Modules would seem to need new constructs to:
>
> *  Import the XSLT / XQuery library modules that implement the tags.
> *  Execute value templates within element text (as with the $last-name
>     and $first-name expressions in the example above).
> *  Process tags as calls to library functions, passing the tag
>     attributes as function parameters and the tag content as a
>     callback (as with the attributes and content of the query:people tag).
>
> A XSLT or XQuery tag library module would seem to need new constructs to:
>
> *  Bind a tag name to its implementing function.
> *  Process callbacks zero or more times as appropriate.
>
> For experimentation, I put together a sketchy preprocessor [4] that
> converts an XHTML tag page and an XSLT tag module to intermediate XSLT
> files and then executes the intermediate XSLT files to produce an output
> XHTML document (supporting callbacks through Dimitre Novatchev's
> technique [5] for dynamic functions).
>
> This preprocessor has significant limitations with respect to callbacks.
> In particular, variables in scope at the definition of the callback
> fragment aren't in scope during processing of the callback fragment.
> One alternative might be to emit the tag implementation inline within
> the converted tag page.
>
> A really robust implementation of tag libraries may need native XSLT /
> XQuery anonymous functions.  (Having just noticed Dynamic Function
> Invocation [6] in the XPath 2.1 working draft, I'm wondering if that
> would help.)
>
> Anyway, that's the idea.  What do you think?  Wrongheaded?  Worth
> pursuing?
>
>
> Erik Hennum
>
>
> Acknowledgments:  The thought was triggered by a talk about virtual
> documents [7] by Vyacheslav Zholudev at the Balisage conference.
>
>
> [1] http://en.wikipedia.org/wiki/JSTL
> [2] http://www.w3.org/TR/xslt20/#simplified-stylesheet
> [3] http://www.w3.org/TR/xslt20/#dt-attribute-value-template
> [4] http://docs.google.com/leaf?id=0B_yrFnrTAZDGNGY3MjI2MTgtZGZjMS00ZDUwLTljNjgtNDg1NDdhNzY4NDE5&hl=en
>      CAVEAT:  only an experiment, may change completely or be abandoned
> [5] http://fxsl.sourceforge.net/
> [6] http://www.w3.org/TR/xpath-21/#id-function-invoke
> [7] http://www.balisage.net/Proceedings/vol5/html/Zholudev01/BalisageVol5-Zholudev01.html
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>