Re: Combining multiple *sources* ( WAS: documents (WAS : xml & forms revisited)

[Paul Tchistopolskii <paul@xxxxxxx>]

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