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

[Erik Hennum <efhennum@gmail.com>]

Hi, Philippe:

Thanks for the reference, RefleX looks impressive and ambitious
(a kind of all-in-one environment).

As you suggest, my question is much more modest:  what's the
_least_ addition to the XSLT / XQuery ecosystem that would support
contracts between application developers and page designers?

My answer is XSLT Simplified Stylesheet Modules++ with callbacks,
but I'm interested in other opinions (including disagreement that tag
libraries are good or needed).



Erik Hennum


On Mon, Aug 23, 2010 at 6:28 AM, Philippe Poulard
<philippe.poulard@sophia.inria.fr> wrote:
>
> Have a look at RefleX:
> http://reflex.gforge.inria.fr/
>
> It does more or less what you expect: there is a templating language, it is no based on EL but rather on XPath, there are existing libraries for most common usages, you'll be able to define your own tag libraries either with other tags (macro tags) or bound to some Java code, you'll be able to design declarative languages, you'll be able to run XPath expressions upon non-XML objects (such as a file system), it can be run within a servlet or in batch or even embedded in your own app etc etc...
> But the engine within which it works is neither an XSLT processor nor an XQuery engine.
>
>
> 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
>>