Re: The XSL-List Digest V2 #191

[Scott Ferguson <ferg@xxxxxxxxxx>]

> From: Paul Prescod <paul@xxxxxxxxxxx>
> Scott Ferguson wrote:
> >
> > 1) JSP decided to leverage existing languages, like Java and JavaScript.  So
> > the number of extra tags is small.  XSLT decided to create yet another
> > programming language.   So it adds a number of new tags and significant
> > complexity to the pattern language.  Also, XSLT has lost the orthogonality
> > between the pattern language ('XQL') and the transformation langue
> > (xsl:template, etc.)
>
> What does that mean? How are they not orthogonal?

With each draft, 'XQL' needs more XSL declarations to work.  'XQL' now depends on
XSL to work for ids, variables, extension functions, keys, locale, namespaces, and
the doc() function.  The namespaces and extension functions are the real killer.  My
main concern, really, is that the next draft will include more dependencies as XSLT,
solely to avoid the dreaded xsl:script and xsl:eval tags, becomes a full-fledged
functional language.

XQL is still usable without XSLT.  If you avoid those features, you can use XQL
outside of XSL, although namespaces are still a problem.

For example, my Xql api is in a different package from xsl and has the following
static functions:

  Node node = Xql.find(document, "a/b[@c]")
  Iterator iter = Xql.select(node, "chapter/verse");

And also:
  Expr nextChapter = Xql.parseExpr("chapter/@id + 1")
  double count = nextChapter.evalNumber(chapter)

To make XQL work with XSL, I've got an environment class, Env, that you need to fill
with variables, key declarations, id declarations, locale, and pass it as an
optional argument.  Each XSL declaration adds some more random fields to the Env
class.

I haven't yet figured out how I want add Env methods to support the xsl:functions
declaration, especially in a language-independent manner.  And doc looks like a
nightmare.

Namespaces are big problem, because XQL needs the namespace declarations to generate
the pattern.  For example, the following API can't possibly create a correct match
pattern following the April draft, because the parser doesn't know the namespace
declaration for 'jsp':

  Pattern pattern = Xql.parseMatch("jsp:expression")

Is this a major problem for XSLT?  Probably not.  My API getting grungier and more
random with each new XSLT draft is well down on the list of important issues :-).
But I believe Microsoft has a similar API, and the DOM level n + 1 may eventually
support XQL.  So my concern isn't entirely selfish.

Scott Ferguson
Caucho Technology



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list