Re: <xsl:stylesheet xmlns...

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