OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Streaming Transformations for XML

[ Lists Home | Date Index | Thread Index ]

> From: Manos Batsis [mailto:m.batsis@bsnet.gr]

<snip/>

> Good point; that XSLT-like syntax (and semantics) may be both 
> a good and
> a bad thing. From my understanding, this is one level higher but
> directly on top of SAX which isn't exactly the same...
> 
> On the other hand, one may build on XSLT behavior using SAX code. How
> difficult is to reproduce XSLTs "default template" behavior 
> for example.

Reproducing XSLTs "default template" behavior is not always a good thing.
I've always felt that I'd love to have something XSLT-like, but which I can
exercise more explicit control over default behaviors. For instance, if you
wanted to use an XSLT-like mechanism for implementing a web service (rather
than a straight RPC binding), then you certainly don't want a default
template behavior that just copies text nodes to output.

I've been thinking for some time of doing something like this, but have
never gotten around to it. I think my ideal solution, though, would be to
use something that looks somewhat like XSLT, but which lets me specify
lightweight "collectors" -- something like the "variables" in XSLT, but
which collect data from the SAX stream when a pattern is matched. You could
have templates like XSLT that specify a Pattern, then have variables that
collect subordinate data (e.g. data that is along either the child,
descendant, or attribute axes of the node matched by the pattern). When all
of the variables associated with the pattern have collected all relevant
data, fire off some action to do processing with the data.

I think dom4j has something like this, but geared more toward processing its
object model rather than just collecting data from raw SAX events.

I think this could be useful, though. We often hear how XSLT is not the
right solution for everything, but there have been plenty of cases where I
felt that XSLT was about a 90% match for the functionality I wanted -- if
only I could tweak its behavior a bit (and make it work on SAX streams
without collecting data into a DOM or similar object model).




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS