|
Subject: Re: CSS and XSL From: Ray Cromwell <ray@xxxxxxxxxxxxx> Date: Tue, 16 Feb 1999 18:37:38 -0500 (EST) |
The obvious API for me is one that allows me to take advantage of
the query portion of XSL.
For example, a call like this
NodeSet ns = SAXSL.queryNodes(currentNode, "./book[@title = 'foo']");
or ala JDBC
XSLQuery q = SAXSL.createQuery("./book[@title = '?']");
q.setString(1, "foo");
NodeSet ns = SAXSL.queryNodes(currentNode, q);
I recently had an application where I needed to match nodes
in the input tree, however, I didn't need any transformation
at all. I just catch data, and do event processing.
Now, I could use XSL to write out a result tree, and then use SAX
to process the result tree, but that's clearly overkill.
Or, I could use SAX directly, but using SAX is like using Lex.
If I want to match strings according to a context free grammar,
I have to hand code all the stack and query logic.
I'd much rather have something like SQL: Here's my query, give me
a result set, or perform this callback.
Another useful API is a debugging API. At XML98, I presented a hacked
up version of DocProc's XSL processor with a Java front end. The idea
was that one could set "break points" on XML elements in the input
tree or rules in the stylesheet. Then, you could process the style
sheet, single step the engine, and watch visually exactly how the
matcher is progressing through the input tree. I thought it would be
very useful especially for large style sheets with lots of modes,
or rules with differing specificity matching the same nodes.
-Ray
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: CSS and XSL, Paul Prescod | Thread | Re: CSS and XSL, Paul Prescod |
| RE: Simple API for XSL?, Ed Nixon | Date | XSL-List, Year 1, XSL-List Owner |
| Month |