Subject: Re: <xsl:stylesheet xmlns... From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sun, 06 Aug 2000 13:50:55 -0700 |
----- Original Message ----- From: Sebastian Rahtz > > 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. Because it is almost possible to find some solution - yes, I agree, there could be some way / API to do this in principle. But I think this is a complex problem, actually. > > The smart processing model for complex > > XML / XSL client / server apps simply > > *does not exist*. > probably true I'm glad you are not saying that "it is because your data are bad". > > 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. We can, but it will be a piece of paper until it is implementend and it is not possible to see how good is the concept, until trying it in the real life. "Shedule the disaster". This has been invented and described by Brooks 30 years ago and I don't think anything has changed since then. <OT> This is what drives me crazy. The trivial, basic principles of software development are ignored by W3C and everybody's saying 'this is OK'. </OT> > > 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? No matter is it because of IE or because of something else. To me this means that there is no real expereince with this client-side-rendering technology - this means all those speculations on 'Client-side XSLT is good for your client-server' are only speculations. Assumptions and guesses. > 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. Hmm... I think that what I'm doing is explaning that that there are some ways other than W3C dogmats. And I'm questioning some of W3C dogmats ( like 'no-side effect' ). In your terminology I'm not the inquisition, but I'm heretic with all that that SML stuff , streaming stuff e t.c. When questioning any W3C dogmata there is 3 kind of reaction you can get: - silence, because nobody understands you - you are blamed for incompetence, because 'questioning the dogmat which is set by gods means you should be stupid' - reasonable on-topic feedback. ( rare, but it is the purpose of this game ) Because most heretics are mostly receiving reaction (1) or (2) but not (3) this ocassionaly and finally makes those people ( heretics ) to write nasty letters. My case is of course really clinical case, but I found that in general - some other "heretics" are now writing the letters which they'l never write a year ago ;-) Being a heretic for a while is no good for you personality. ;-) > XSLT is still new After 5 years of development it 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. Hm. I may be too cynical, but I think that because James Clark has dropped XT there will be no XSLT 2.0 And I doubt there will even be XSLT 1.1 ;-) Also - there are too many dogmatas to change. This is too late, too late, too late ... If it will take 5 more years to get XSLT 2.0 - we have the situation we have with 'ideal SQL' standards. Situation with SQL is that mySQL is powering most of the boxes on the planet. What I'm doing - I'm trying to get a feeling what will people do with the mySQL of XSLT. I'm not blindly blaming XSLT - I'm trying to make the next step. In your universe the 'next step' is to pray for XSLT 2.0 to 'fix' some craziness, to wait when all of SQL vendors will implement that 'ideal SQL". In my universe 'the next step' is : implement mySQL. > 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? Well - to me this *all* was questionable when I have started with your usecase. > 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? The conclusion I draw is that I'l for sure not have key() and *maybe* I'l also drop 'sort' in 'mySQL of XSLT' . Another conclusion is that I should add some components to UX ASAP because wihout those components people don't understand why pipes of transformations should be the rule, but not the 'exotics'. The surprize ( even I was predicting that ) was that if writing 'the same' in 'one stylesheet with no key()' it will be 20-50 times as slow and again less readable than pipe. Also it looks like UNIX 'sort' was not than stupid component, but it also looks like XML forces some realy new filters to appear - ah, sorry it is again not XSLT ... I again feel I'm off-topic generator. This is all frustrating. Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: <xsl:stylesheet xmlns..., Sebastian Rahtz | Thread | Re: <xsl:stylesheet xmlns..., Sebastian Rahtz |
RE: <xsl:stylesheet xmlns..., Chris Bayes | Date | Re: <xsl:stylesheet xmlns..., Paul Tchistopolskii |
Month |