Re: <xsl:stylesheet xmlns...

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