Re: [xsl] Reading XSLT results into a program (long)

[cutlass <cutlass at secure0 dot com>]

Don Bruey wrote:

> 
> Does anyone have thoughts on this that would contradict what I've concluded
> above about storage or ease of manipulation of XML data?  Do you have a way
> you always read data that always brings it in the same way using XSLT?   I'm
> not saying my view on this is absolutely correct - honestly, I'd love to
> have someone tell of a solution they've had to this issue.  I know that
> XSLT/XML are good for what they're good for, and that there is no
> one-size-fits-all storage mechanism, but it would be interesting to know how
> other people handle routine reading and handling of XML data via XSLT.
> 
> Thanks.

not necc an xslt question, but i''l add some thoughts to your questions;

an intemediary step, inteferes with our 'cathedral' view of xml, but i 
find that the intemediary step of seperating the requirements for long 
term data storage from short term data is good.

a)  i frequently use mysql for raw storage, which contains xml and a 
primary index key, so i use the same sql statements for add,edit, delete 
for everything , this can be favorable for porting between application 
frameworks ( perl,asp,coldfusion,etc ); what about normalising tables, 
and all that other stuff we've been doing with SQL for the past decade 
?  well, using xml/xsl is forcing me to do a lot of refactoring. all my 
xsl also goes into a database, which means i have versioning, and backup 
of logic code dealt with.

b) using a relational db allows me to make a logical module/break for 
archiving and data back up, which is can be cleaner in real use, that is 
when i need to revive a database ( back to some date in time or some 
previous state ), there is none of the typical sync problems one can 
encounter in a very large db structure with 100's of linked tables, i'm 
remembering some painful oracle moments with a few corrupted tables.

c) the xml databases on offer at the moment, are like most of the suite 
of xml technologies, bubbling with emerging specs and sometimes 
proprietary methods, i am waiting for the time to review the current 
offerings and expect to implement a std long term storage solution that 
is in a native xml repository ? at xml-dev list

d) once i learned how to manipulate data with xsl, i had a common 
language for transforming data in most environments, i just redid a 
Topic Map navigation device, i originally developed in c++,  in 
macromedia flash. the same thing different syntax yes, but the logic is 
completely the same.  one can say the same thing about the std nature of 
SQL (even thought there are some variants in the wild ), but in real 
life i would expect to find an xml/xsl parsers in those tactical areas 
where a full blown database would never inhabit.

f) for me at the moment, very simply,  xsl transformation results (xml) 
are either pipelined into other xsl transformations or stored into a 
relational databases or file,. or further manipulated in memory.  i 
would publish data to a csv,only if there was an external requirement, 
or read data in csv if thats what an external program generated, but i 
think u could just save your 'user settings' ex as xml  if u were just 
using the parser ???? maybe i dont understand

once again, this really isnt an xsl question, but i agree that for the 
short term this can be a bit tricky.

, jim fuller


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list