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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Streaming XSL Stylesheets - Was: XML::Writer 0.1 available

[ Lists Home | Date Index | Thread Index ]
  • From: Alex Milowski <milowski@dnai.com>
  • To: David Megginson <david@megginson.com>
  • Date: Fri, 23 Apr 1999 13:06:29 -0700 (PDT)



On Tue, 20 Apr 1999, David Megginson wrote:

> Eric Prud'hommeaux writes:
> 
>  > I'd love to differ with you here. In practice, I can't, but in
>  > theory... I have this itch to work out and implemnt an XSL parser that
>  > works as as a SAX stream. Given an XslStream that reads the parsed
>  > stylesheet from an XslDB and has an output SAX stream $this->{OUTPUT},
>  > the notion is something like this:
>  > 
>  > parser reads "<someTag attr1='value1'>"
> 
> In DSSSL, such a thing was not possible because there were
> unpredicatable dependencies -- for example, you might find this near
> the front of the document:
> 
>   <gloss id="x">...</gloss>
> 
> But you wouldn't know that you had to do something useful with it
> until you found this near the end of the document:
> 
>   <annotation source="x">...</annotation>
> 
> In the general case, then, a stream-based DSSSL processor would
> *still* have to cache the entire document, since it allowed arbitrary
> navigation.  I don't know if the same applies to XSL -- I'll have to
> give the spec a closer look.
> 

Not quite.  You could develop a stream-based DSSSL processor given that
you do the appropriate analysis of the stylesheet upfront and determine
where "caching" would have be put into place.

XSL has the same problem except that it is much more clear when things
would have to be "cached" and "unrolled" when the select patterns were
satisfied.  Further, if you have DTD (schema) you can determine when a
pattern can apply with the instance and make the stylesheet processor 
operate much faster.

The issue for XSL is that it is still a hard problem to solve and one
might question what the benefit would be over a tree-based solution in
that development of a fast XSL processor should be possible once the
tree is assumed.

I did some experimentation with stream-based application of patterns and
select statements within templates.  It is possible and the result is
extremely promising.  What struck me was the complexity that resulted
because of the combinatorics of the problem as a whole as well as the
necessity of a really smart compiler.

 
R. Alexander Milowski                                         milowski@dnai.com
               Remember: Stressed spelled backwards is desserts.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

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

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