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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: transformations

[ Lists Home | Date Index | Thread Index ]
  • From: Didier PH Martin <martind@netfolder.com>
  • To: Chris Lovett <clovett@microsoft.com>,"'Steven E. Harris'" <steven.harris@tenzing.com>, xml-dev@lists.xml.org
  • Date: Tue, 21 Nov 2000 08:11:02 -0500

Hi Chris,

Chris said:
I agree a forward-only streamable subset of XSLT/XPath would be very useful.
Upon further investigation streaming-transformations may turn out to be a
completely different animal.  When you change some fundamental assumptions
(like random access in XPath selections) it is wise to revisit the entire

Didier replies:
As you know, the XSLT design is based on the DSSSL design. In this latter,
the basic assumption is that any process is peformed on a list. As you know
also, list are one of the basic data structures available in Scheme (a lisp
subset). Having worked all the year on the DSSSL version 2 specs. Living the
limitations we are mentionning in this list since several years (long before
XSLT I should say :-), I started to take a look at Omnimark which, as you
know, is a simple pattern match made not on a structure but with the text.
Thus, Omnimark is a classical example of a forward-only processing engine.

Up to now, I noticed that most of the XPath constructs can be used for
forward-only processing. The construct which requires backward reference is
the <xsl:apply-templates select=""/> construct. I am still investigating in
Talva's labs (Just a bigger Didier's labs with more people :-) the impact of
removing the <xsl:apply-templates.../> construct and keeping only the
pattern match. In fact, I am trying to figure out what are the
transformation made not possible by this kind of omission. Have you
investigated this? Any clues to share? My early findings is that it is very
hard to include a transformed  tree branch in the output result when the
<xsl:apply-templates..../> is omitted. I think the key is to take a close
look on how Omnimark is doing things.

Chris said:
 I also like the idea of throwing in regular expressions while
you're at it.  (Hey, the Schema guys got away with it -
http://www.w3.org/TR/xmlschema-2/#regexs :-)

Didier replies:
Now we are definitively talking about something very similar to Omnimark. I
think these guys are actually smiling to see us struggling with concept they
implemented a decade ago :-)

Didier PH Martin


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

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