Re: [xsl] XSLT & SQL

["Thomas B. Passin" <tpassin@xxxxxxxxxxxx>]

[E L]

> Someone told me that he can do *any* XSLT transformation in SQL. Here's
the
> premise: any input XML document can be represented by one or more tables;
> likewise for the output XML document. The XSLT can be replaced with an SQL
> insert statement, selecting from the input and inserting to the output
> (e.q., any XPath expression can be expressed by a similar WHERE clause in
a
> SELECT statement).
>
> I can see it's possible for simple document. Are there instances where
this
> would not be possible?
>

Do you mean without the help of stored procedures that can be used in
queries?  Or is the SQL-master allowed to use procedures to help?  Are
vendor extensions, like those used to help build bils of material, or to
construct trees, allowed?  Are we talking about SQL92 or the newest version,
which allows composite objects to be cell values?  Are we talking about
using a single query or can the SQL-master stitch together the results of a
series of queries with some external code?

I'm highly doubtful that it can be done without procedures - how would you
be able to apply namespace rules, for  example?  Or set up rules equivalent
to predicates like [A=B] where A and B are nodesets?

But even if it could be done, I can't imagine actually building the queries
needed, debugging them, and maintaining them.  Maybe your friend has some
clever table designs that could make it easier, or maybe he is thinking.
But xml and xslt have so many rules that are specific and detailed that I
just can't see it (in general, there could be some class of problems that
would work OK).

At one point I had some fun - I came up with a fairly easy way to represent
(element-only, no namespace) XML with a column for the element's path (yes,
like '/A/B/C')  (actually, there was a separate table for the unique paths,
and the element table had a foreign key pointing to the path table).  It was
easy to insert the data using a python script.  It was simple to do basic
queries, including wild-carding steps of the path.

I put the well-known Hamlet.xml into the database.  You could easily
retrieve all the scenes in which Hamlet spoke, for example, and things like
that performed pretty well.  But it got impossibly complicated when you had
to deal with queries of large or unknown depth into the tree, or when you
had to match content of element names across several levels of nesting.

Any simple scheme like this cannot output XML, because it cannot wrap the
results in a root element.  You would certainly need something more complex
if you had to output XML.  Well, it was interesting but it does not prove
anything about the original question.

Cheers,

Tom P


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