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

Subject: Re: [xsl] Reading XSLT results into a program (long)
From: cutlass <cutlass@xxxxxxxxxxx>
Date: Fri, 19 Jan 2001 15:32:54 +0000
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.


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:

Current Thread