Subject: Re: Combining multiple *sources* ( WAS: documents (WAS : xml & forms revisited) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Fri, 10 Mar 2000 18:30:52 -0800 |
Hi Eric > > PXSLServlet ( dirty trick by definition ) solves this > > problem in another way, attaching the environment > > variables into XML *source* document. > > > > That means in the stylesheet we have only > > <xsl:value-of select="/request/variable"/> > > or something like that. ( It is flexible - S2X Template > > determines the actual names for 'request' and 'variable'. ) > > > > Of course, that's because in PXSLServlet's universe > > there is "S2X magician", responsiple for grabbing > > XML data from the outher space ( mostly > > SQL database), and because environment of http request > > is "yet-another-data-source" - those data are pulled > > into source XML by S2X template and do not go to the > > stylesheet. "stylesheet is about processing, S2X template > > is about the dataflow ( XML-to-process )". > > > > In the absence of S2X 'magician' there is no way to > > compose the desired source XML on the fly, so > > your solution is perfect from my point of view. > > > > Just wanted to explain what I meant yesterday saying > > that "in PXSLServlet, XML is about the data and XSL is about > > the processing" > > > > - in your universe some data are jumping into the text of stylesheet > > - in PXSLServlet universe - data are jumping into XML source, stylesheet > > assumes the data are already in the XML-document-to-be-processed > > ( the stylesheet tries to be 'ideal' ;-) > > > > My universe has a lot of other problems of course ;-) Also your 'jumping' > > of data into the stylesheet is very compact - just a couple of lines. > > That means I realy don't think my universe is in any way 'better' than > > your's - just wanted to show some other point of view ( BTW, the PXSLServlet's > > tactics with the environment variables explained above is just a side-effect of > > SQL -> XML mapping). > > I must be slow, but I am just beginning to understand that S2X can be > used for much more usage than SQL to XML mapping ! S2X is actualy 'something to XML' ;-) My original idea was: 1. XSL is good 2. The input to XSL is XML. 3. That means if I want to process 'something' with XSL I need to turn that 'something' into XML on the fly. The first 'something' was SQL. The second 'something' was HTTP request. In the next versions there will be support for some other 'somethings', like XML files, CSV files, probably Excelon, OODB's e t.c. > The <XML>fr front page (http://wmlfr.org) for instance is reading, in > addition to the index.xml page and the XSLT sheet, 7 XML pages (a site > and page layout xml document which is common to all the pages and 6 rss > document with the headlines of the 6 sections which are displayed). > > This is more complex to explain than to implement and I'll publish all > this when I'll find some free time... It is very understandable to me ( the idea of PXSLServlet was to give a generalized solution for such scenarios ). The purpose of S2X is to make the work with multiple *data* sources transparent from XSL stylesheet's point of view. Multiple XML files is just once case of multiple sources. The problem gets more complex when behavior of one source should be affected by another source ( not everything should be dumped from SQL table, but only part of it depending on some variable of HTTP request is an example. But there could be some more complex dependences ;-) For example - it could be possible to 'join' SQL table, CSV file and some XML configuration file into one XML file, like it is now possible to join HTTP request with SQL tables to produce the resulting XML. > Let's say that it's done by applying the templates on the "site and page > layout" xml file which is containing pure XHTML elements plus specific > embedded elements whose templates are inserting the specific parts in > the page. > > These specific parts are stored in the index.xml (specific) file and are > also containing XHTML elements with "call back elements" whose templates > are inserting the data from the rss files. > > BTW, I am amazed by the speed with which XT is handling this complex > transformation involving so many files... Yes, XT is very fast. But with S2X | XSLT pipe I can use SQL sorting, for example ( even I could use XSLT's sorting ). For some cases utilizing XSLT's sorting is not a good idea. > As an alternative, I could have included all these files directly into > the tree using external entities in index.xml. > > I have done so for other projects, but, for various reasons, I find it > less flexible... > > Would S2X be also able to combine all these files into a single XML tree > ? S2X will be able to combine anything with anything, producing the single XML file, so that XSL stylesheet should not bother with such activity. In UNIX terms, instead of using "standalone XSLT" building block, PXSLServlet is adding one more component to the pipe: S2X | XSLT > output There are actualy some other ideas ( pipes could be and should be longer ;-), also the syntax of S2X is still changing ( any help with the syntax from a preson with better style than mine is welcome.). Finding time is always a problem. On another hand, the source code of PXSLServlet is open and I estimate not longer than 2 days for any developer to expand S2XDescriptor to accept XML files ( or CSV files), but not only SQL tables / HTTP-requests. Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Combining multiple documents (W, Eric van der Vlist | Thread | RE: XML spec for UI?, Arnold, Curt |
Re: xsl for formatting, violet wright | Date | RE: Some Questions (2nd try), Chris Bayes |
Month |