Subject: Re: The XSL-List Digest V2 #191 From: Paul Prescod <paul@xxxxxxxxxxx> Date: Sun, 27 Jun 1999 12:52:00 -0400 |
Scott Ferguson wrote: > > 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. What you're saying is that every version allows a richer binding between the embedding environment and the query. This is no different than SQL or OQL which also allow the defintion of (e.g.) extension functions. > The namespaces and extension functions are the real killer. How would you propose to avoid those? One could, theoretically define an alternate syntax for the query language that allows the namespaces to be spelled out as URIs, but surely you don't think that that should be *required*. And extension functions are crucial for making the query language extensible -- whether in XSLT or anywhere else. SQL and OQL are both designed to allow the environment to add extension functions also. > My > main concern, really, is that the next draft will include more dependencies as XSLT, XSL has been declared feature-complete. It has also been declared that most of XSL's query language will be unbundled for use in XPointer. > solely to avoid the dreaded xsl:script and xsl:eval tags, becomes a full-fledged > functional language. You haven't established any relationship between the environment-embedding features of XSLT and XSLT's lack of support for inline scripting. It looks like a red herring to me. > 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 don't see this as a big problem. In SQL and OQL these extensions are just embedded in the database. Probably future XML databases will also offer this option. > 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. I don't see your environment object as being grungy. It falls out fairly naturally from the description of "context" in the XSLT draft. XSLT has one syntax for setting up the context and of course your library will have a different one. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Perhaps the war in Kosovo would get more press if it were directed by George Lucas. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: The XSL-List Digest V2 #191, Scott Ferguson | Thread | attribute value templates & javascr, Jim Palmer |
RE: XSLT vs JSP, Joseph A. Latone | Date | RE: XSLT vs JSP, Joseph A. Latone |
Month |