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