[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SML] Whether to support Attribute or not?
On Sat, 27 Nov 1999, Paul Tchistopolskii wrote: > S-XSLT should be written anyway. XT will hardly fit into > cell phone ;-) > > S-XSLT processor should be much easier to write than > it was to write XT ( the same is with SML parser, S-SAX, e t.c.): Question: how far does this go? If we have SSLT, would we also have SLink, SSchema, SPath (well, obviously we'll have that; no matching on attributes), ...? How about SHTML? Admittedly it is fun having the X-people do some work, then come along a year or two later, with perfect hindsight, to create a better spec. Besides, the deserve it, since they have done the same to SGML :-) Is this a way to resolve the problem of trying to build specs in Internet time - "must get it out the door, we'll re-think it in the next generation"? I have mixed feelings about this... Clark C. Evans <clark.evans@xxxxxxxxxxxxxxxxxxxx> wrote: > I'm all for this; the SSLT definition should be > stream-only; in otherwords, it should not require > random access to the entire SML stream. 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. 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. Sorting and numbering always require another "pass". We can either: - Keep the XSLT model, which requires a buffer large enough to hold all the sorted input tree fragments. - Change the model so that sorting would be done on output tree fragments. This reduces the language power in some ways. - Disallow sorting altogether. The second option is based, again, on the assumption that the result tree is smaller then the input tree. Its consequences are: - Templates are _always_ called in document order, even in sorted invocations (important due to side effects). - The computation of 'position' operation in sorted invocations would be delayed until the sorting pass. Doing a delayed 'position' computation would complicate the SSLT processor, unless the use of this function is restricted to being embedded inside the output tree. In particular, it would be illegal to use it in a condition or in side effects. This way the SSLT processor could simply do the embedding as part of the sorting pass. Have fun, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
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
|