[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Streaming Transformations for XML

• To: "'Manos Batsis'" <m.batsis@b...>, Petr Cimprich <petr@g...>
• Subject: RE: Streaming Transformations for XML
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Thu, 14 Feb 2002 12:49:51 -0800
• Cc: xml-dev@l...

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

<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).

• Follow-Ups:
  • Re: Streaming Transformations for XML
    • From: Petr Cimprich <petr@g...>
  • Re: Streaming Transformations for XML
    • From: Paul Prescod <paul@p...>

• Prev by Date: [Announcement] First version of W3C DOM Level 1 Core Conformance Test Suite released
• Next by Date: Table in DTD
• Previous by thread: RE: Streaming Transformations for XML
• Next by thread: Re: Streaming Transformations for XML
• Index(es):
  • Date
  • Thread