Subject: Re: The XSL-List Digest V2 #191 From: Scott Ferguson <ferg@xxxxxxxxxx> Date: Sun, 27 Jun 1999 16:12:18 +0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Numbers above 128 !, Scott Boag/CAM/Lotus | Thread | Re: The XSL-List Digest V2 #191, Paul Prescod |
Re: Numbers above 128 !, Eugeny Kuzakov | Date | RE: XSLT vs JSP, Joseph A. Latone |
Month |