Subject: Re: Cascading. ( Re: Recursive Template Application ) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Tue, 20 Jun 2000 11:22:24 -0700 |
From: Matt Sergeant > What I was saying was that you shouldn't have to specify the > stylesheets on any command line or in the querystring. Why? I think it is better to see what realy happens, what stylesheets are applied e t.c. BTW, in UX, because there are aliases similiar to UNIX, the command : cat some.xml | aggregate.xsl mode="terse" | expand_widgets.xsl | render2html.xsl font="big" could be described in /etc/aliases.xml <alias name="do_it" cmd="cat $1 | aggregate.xsl mode='terse' | expand_widgets.xsl | render2html.xsl font='big'" /> And will be invoked accessing url /ux/Uxs?cmd='do_it%20some.xml' So even the processing is complex - the 'things' are easy to maintain, I think. I think this is for sure easier to understand than 'alternate', 'persistant' e t.c. cascading stylesheets. When something is easeir to understand - I think that 'something' works 'better'. I like simplicity of UNIX and I don't like complexity of SGML. > AxKit does exactly > what a browser is meant to do: picks up the transformations from the > originating document via the <?xml-stylesheet?> processing > instructions. I'm sorry if I confused things by using your > "cat" command. I should have said its more like: > > "process some.xml" > > Where the process command picks out the stylesheets to use. > > (Note that for anyone interested in AxKit put off by this because it > doesn't scale well to 1000's of XML files, its all overrideable in various > different ways that do scale better) What do you mean? > In AxKit XSLT transformations don't have access to the querystring > parameters... yet. Its probably a bug. However you can use XSP or > XPathScript in places where you need access to the querystring. In AxKIt XSLT transformations don't have access to parameters ????? I don't understand how are you using XSLT then. In Ux, XSLT stylesheets not only have access to external parameters, but are storing / reading data in presistant HTTP sessions, cookies and do a lot of other stuff. ( In fact my original idea is to do almost everything in XSLT and I like how it works ). I found XSLT to be good programming language ( even verbosity is annoying and there are 2 other things waiting to be fixed - but let's go step by step ;-). XSLT has some flaws, but I have to say that if I understand right that AxKit XSLT stylesheets have no <xsl:param top-level elements - AxKit point of view on XSLT stylesheet is very, very, very limiting to XLST developer. > > > Right. I'm not trying to flog AxKit to everyone here - most people will > > > prefer a Java solution anyway (poor lost souls ;-)), just trying to point > > > out that there is a standard for cascading that applies to XSLT. > > > > I don't think it makes too much sense with XSLT. > > Can you explain why? Obviously the W3C disagrees with you. We've discussed > before how it doesn't exactly scale well to edit <?xml-stylesheet?> > processing instructions into 100's or 1000's of XML files (but AxKit can > cope with that too), but is there any other reason you think it doesn't > make sense? Because XSLT is not 'a bit better CSS' but it if full-blown ( and darn nice ) programming language for XML processing ( not the end of the story, but ;-) W3C is just inheriting their practices from one domain to another. >From SGML to XML, from CSS to XSL. To me it is not too much sense. I agree that it may work for cases when XML + XSL combination is used for producing one and only one HTML file ( ever ). ( But when I have such a situation, I'l better to write only one file ( XSL in HTML-ish template form ) - ( still no need in hardcoded bindings ) ) OK, OK - people need this way of binding for client-side ( I mean they think they will need it for XSL because they need if for CSS ), but because I not expect reliable client-side implementations of XSLT to appear in the near future, I'm discussing real world. In the real world I *never* got the situation which forced me to insert <LINK into XML file, binding it to some XSL stylesheet. > > BTW - is Salbotron SAXParser? Is it providing parse() and > > setDocumentHandler() to the perl code? If yes - you can > > have the same document( "/! perl-bean1 | perl-bean2" ) > > in perl. Ux pattern is universal and should be easy to > > re-implement in any language, because it is plain SAX > > and nothing more. > > Sablotron allows you to provide scheme handlers, so I could add a scheme > handler for "axkit:" and so support document("axkit:perl-bean1 | > perl-bean2") or something like that. This isn't in the XML::Sablot > interface yet, but its in the Sablotron interface, and I'm discussing > adding it to the Perl interface for the next release so that AxKit can > handle EPE's and document() better with Sablotron. Sounds interesting. But if Salbotron is not SAXParser you may find that chaining is not as flexible as you would like, ( for example, there could be no way to do: document("axkit:perl-bean1 | transformation.xsl") ( Supported by UX, because when everything is SAX - that rulezz ;-) Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Cascading. ( Re: Recursive Temp, Matt Sergeant | Thread | Re: Cascading. ( Re: Recursive Temp, Matt Sergeant |
RE: counter, Jeni Tennison | Date | XSL Question, Victor Rodriguez |
Month |