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

Re: A weaker XSL?

  • From: Clark Evans <clark.evans@m...>
  • To: Tyler Baker <tyler@i...>
  • Date: Thu, 04 Feb 1999 19:26:05 +0000

Re: A weaker XSL?
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@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.