Subject: Re: <xsl:stylesheet xmlns... From: "Sebastian Rahtz" <sebastian.rahtz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> Date: Sun, 6 Aug 2000 16:49:03 +0100 (BST) |
Paul Tchistopolskii writes: > What do you mean by saying "I'l deliver the main data file > to the client, and a slew of .xsl files" ? The <xsl:stylesheet > directive provides one - to -one binding. I mean you use > this directive to say : "this XML file should be rendered > with this xsl stylesheet". but I do not use the directive (in real life). > How can you deliver main data file and a slew of small > .xsl files using <xsl:stylesheet directive? I could, actually, provide many small data files, each with its own stylesheet directive, and each referencing one big data file which the client would/could cache. > Or you are talking about some proprietary-absolutely > non-standard-vendor-specific API which allows you > to associate the same main data file with multiple > xsl stylesheets ? I don't think the W3C tells me the One Way how to run an XSL processor against a data file. It provides a notation for the one-to-one situation, but does not deny other methods. > mentioned above also has some problems and this > makes the senario you are describing to be very much > hypotetical. ( I mean static vs dynamic + caching is > a problem ). hey, let me make it clear that I am not proposing anything! I am not trying to build a production system of this data at this stage, I am merely talking in a very general way. It just seems to me a not impossible scenario that we will one, at some stage, deliver one data file with multiple stylesheets. > The smart processing model for complex > XML / XSL client / server apps simply > *does not exist*. probably true > Those who are saying > it does exist should have something > to show. In the form of working app, I > mean. I don't see why. We can describe such a model without having a working implementation. > Sofar *all* of XSLT client/side/rendering relatively > complex ( other than trivial ) pages which I saw > are simply failing in unpredictable fashion with > some versions of MS IE 5.* so? IE 5 (July) does not claim to be a finished product, or designed for production, does it? You seem determined to pin people into corners, Paul, when there is really no need. You act like an Inquisition, forcing people to come down one side or another of a religious dogma, when most people (so far as I can see) are still very undecided about it all. XSLT is still new, and maybe the W3C group got it wrong. Maybe key() isn't needed, maybe node-set() is. Maybe the sort model is wrong. Maybe we need a primitive group-by. Why do we have to decide NOW that XSLT is or isn't right? Isn't that what this list is for, to discuss the issues and give input on XSLT 1.1? Maybe XSLT 2.0 should deprecate key() and make it an optional part, who knows. So far as the key() business goes (and my Muenchian use of it in my test6), you are proving (not much to my surprise) that you can do the same thing a) without key() in single pass XT, and b) in multiple pass (using a pipeline approach). You rightly say that the Muenchian code is fairly unreadable, and a pipeline approach is more general, more powerful, and more readable. You also rightly doubt that data of this could is stored in an XML text file. So? The conclusion I draw is that the programmer faced with a problem may choose different methods depending on circumstances (there is more than one way to do it, as Perl folk spout all the time). *One* way may involve a constraint that the whole thing be in one pass, with unextended XSLT. Yes, of course it would be a silly constraint, most of the time, but who knows? Sebastian XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: <xsl:stylesheet xmlns..., Chris Bayes | Thread | Re: <xsl:stylesheet xmlns..., Paul Tchistopolskii |
Re: Bug in 'xsl:sort'. ( XT vs SAXO, Jeni Tennison | Date | RE: Saxon VS XT, Chris Bayes |
Month |