Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fw: [SML] Whether to support Attribute or not?
 On Mon, 29 Nov 1999, Oren Ben-Kiki wrote: > SSLT would have simplified XPath syntax, since there is no issue of > attributes. If SSLT is to be written in SML, the XSLT syntax would have to > be reworked, but this is pretty mechanical - in fact it could be done > automatically both ways (using an XSLT stylesheet :-). So far, this doesn't > gain much. An XSLT processor is complicated enough that it doesn't have much > to gain from SML. > > Making SSLT streaming-only on the other hand, is an interesting notion. I > was always uncomfortable with XSLT's choice of requiring random access to > the input. There are many transformation jobs where the input is much larger > then the output - orders of magnitude larger. Definitely. Let's talk not just about XSLT translation, but about querying in general (which is likely to be based on XPATH syntax and the same sort of data model as XSLT). For example, the TEI crowd is probably going to want the ability to extract fragments from large corpora of text marked up potentially at the syllable level. That's not going to be practical if you're restricted to a data model that requires building a tree for the entire source document. I would say that developing a data model to support streaming query/extraction for XML is a far more worthwhile endeavor than developing a stripped-down data syntax whose main purpose is to allow script kiddies (not to be confused with Desperate Perl Hackers) to repeatedly cargo-cult parsers so that their bosses don't get freaked out by the presence of NIH code, some of which might be (gasp!) Open Source. > > S(treaming)SLT would be different from XSLT in the following ways: > > - A template would be completely responsible for all the sub-tree below the > element it matches; > - A template would be limited to specifying a single pass on this sub-tree > (i.e., a single call to apply-templates, for-each, etc.). > - Therefore, side effects (variable assignment) would be allowed. As I see it, you'd need a way of giving names to path expressions and their result sets, and a way of making one path expression conditional on the success of another. Thus a path expression that goes down the conceptual tree along the child:: axis, then back up the tree along Ancestor::, and then sideways along following-sibling could be replaced with three child::-only path expressions that would have to match in sequence (though not the same order as they would appear in the full XPath expression), each of which would "squirrel away" the conceptual nodes that matched. The idea is to limit the "running storage" required to a stack of element names encountered along the current branch of the conceptual tree and the text content of the current element (along with any squirreled-away data). An interesting question is whether a full XPath expression could be automatically decomposed into a sequence of "sequential-path" expressions. 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 unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
