This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Reading XSLT results into a program (long)


With SQL Server 2000 you can get the best of both worlds.  It is easy to
generate XML direct from the DB in whatever format you need it, including
HTML formatted result sets.  You still have the power and speed of a fully
relational db with the flexibility of xml.

Before 2000 came out the project I am on was storing XML in the database to
avoid a COM+ component having to generate the required XML from a set of
recordset returns.  Different method calls on COM+ components had different
transformations associated to produce the flavor of XML needed.  With 2000
the data is stored in relational tables and there are stored procs that
product the required flavor of xml, transformations are not really required
anymore for almost all of the display tasks that the system has.  The only
transformations in use are those that perform some client side calculations
based on data received in xml format.  Similarly saving data to the DB has
been made much easier since, in 2000, a stored proc can accept an XML
document and perform the required save.

XML is used to send and receive information between the internal system and
outside companies and between the server and client machines.  SQL Server
2000 is used for data storage and retrieval.

No matter what media you are using for data transport or storage, there
needs to be some level of understanding on structure and data format.  In
that sense there isn't a difference between XML and recordsets.  Both have
structural rules, but in determining how to display or organize that data
contained there, these rules are not as important as being able to identify
the information contained in the media.  For that you need to know field
order or naming conventions in recordsets, same for nodes and attributes in
XML.

-----Original Message-----
From: owner-xsl-list@lists.mulberrytech.com
[mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Don Bruey
Sent: Friday, January 19, 2001 11:11 AM
To: xsl-list@lists.mulberrytech.com
Subject: RE: [xsl] Reading XSLT results into a program (long)


The XSL-ness of the question is in the output of the transformation - I want
to use XSLT to filter/sort my XML data.  It's not really an XML question per
se.  I would like to have a "neat" way of always transforming into some
format of data, like SQL gives you when it produces a resultset for you.

I think the answer is that there isn't a way - that's what I was looking
for, hoping not to have missed some obvious or clever way to handle XSLT
output.   Tools such as XSLT have to be considered when making the choice of
relational DB vs. XML storage and I am asking the question in that respect.
Thanks to all who responded.

Don



-----Original Message-----
From: cutlass [mailto:cutlass@secure0.com]
Sent: Friday, January 19, 2001 10:33 AM
To: xsl-list@lists.mulberrytech.com
Subject: Re: [xsl] Reading XSLT results into a program (long)


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.


Jim Fuller wrote:

>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.


>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

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]