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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: A weaker XSL?

[ Lists Home | Date Index | Thread Index ]
  • From: Clark Evans <clark.evans@manhattanproject.com>
  • To: Tyler Baker <tyler@infinet.com>
  • Date: Thu, 04 Feb 1999 19:26:05 +0000

Tyler Baker wrote:
> 
> Nathan Kurz wrote:
> 
> > Also, while the entire stream has to have been read, does it have to
> > have already been processed?  The way I was interpretting the spec,
> > the DOM model didn't exclude a lazy processing method.  So long as an
> > implementation provides a compliant interface, can't it do anything it
> > wants with the data, even so far as to put off processing information
> > until it is requested?
> 
> Actually this is legal, just that when over you iterate over nodes, 
> a Node needs to return the expected data. 
> If you are reading things from a stream, then you obviously cannot 
> just make random accesses throughout the stream to lazily evaluate 
> your data because streams are inherently sequential. 

Yep.  Perhaps the weak-XSL could be based upon SAX instead, then
you won't be suprized.  In this case, the XSL processor would contain
both a DOM and SAX implementation. 

If the XSL sheet was "weak", then the processor could implement 
it's processing from the SAX output.   Otherwise, if it is the 
"strong" variant, with sorting and table of contents, etc, then
it would use the DOM implementation.

Also, if the processor was built upon a memory image, then SAX becomes
an Iterator over the DOM object.  If the processor was built upon
a stream input, then the DOM object is constructed from the
SAX output.

This seems like it would be a really nice ballence.

> For a DOM document that is merely an interface to a DBMS, this lazy
> data model approach you suggest may indeed be the optimal solution 
> for that particular implementation.

Perhaps.  However, many relational databases use a "stream" based
approach 
internally, expecially in cases with large merge/joins.  The result set
is definately returned in a stream, having a bunch of small queries
would
bring performance to a crawl since set operations could not be used
effectively. This behavior definately depends upon the query and 
how it is optimized.

Thus, you may find that a SAX-like stream based interface on
top of a relational database may perform much better than an
DOM-like object based interface!  Perhaps a hybrid object/stream
solution would work the best when a relational database is a primary 
data source...

:) Clark Evans

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