From: Bryan Rasmussen (bry@itnisk.com)
Date: Tue Dec 11 2001 - 11:32:08 CET
Here I have some logical misgivings, cause it seems to me you'd be imposing
restrictions on exsl:document, I mean that if someone has accessed the
database via a web site, I could foresee a use for exsl:document, or
xsl:document to dynamically write to a particular folder in the filesystem.
But then if the database is expecting xsl:document to update the document
set?
>><exsl:document href="myDoc.xml">
>> <foo>
>> <bar>This is the document I'm adding.</bar>
>> </foo>
>></exsl:document>
-----Original Message-----
From: Evan Lenz [mailto:elenz@xyzfind.com]
Sent: 11. december 2001 07:45
To: Bryan Rasmussen; transquery-discuss@lists.oasis-open.org
Subject: [transquery-discuss] XSLT as an XML update language (was Re:
anything other on the namespace than input?)
Bryan Rasmussen wrote:
> I can currently just see three extremely useful transquery methods, input,
> temp(or pipeline, whatever), and save, with save b eing used to create a
new
> document set. Of course xsl:document or exslt:document could be used for
> that, but then the database would have to support a method for using those
> elements to write to the database.
I agree with your assessment of what ultimately needs to be defined for a
straight story on XSLT-based data management. I wish that xsl:document was
already a part of XSLT! Since it isn't, then we either have to wait for XSLT
2.0, commit to the use of extensions a la exsl:document, or come up with a
transitional use of exsl:document which can be later replaced by the
mechanism that XSLT 2.0 eventually provides us.
We can say things like, "Here's how you add a document to an (E)XSLT-based
XML database:"
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exsl=http://exslt.org/common
extension-element-prefixes="exsl">
<xsl:template match="/">
<exsl:document href="myDoc.xml">
<foo>
<bar>This is the document I'm adding.</bar>
</foo>
</exsl:document>
</xsl:template>
</xsl:transform>
Even without having native write semantics in XSLT, we could then get by
with using XSLT itself as an incremental XML update language with
copy-everything-but-what-I-want-to-change semantics. I'll show you what I
mean.
Suppose we have a stylesheet module that's always available for importing,
called "update.xsl". It uses the TransQuery input parameter to access a
collection of documents. It also uses another extension function (which
isn't yet defined by EXSLT, I believe) for accessing the base URI of a given
node. This stylesheet is not something the user has to see, but only to
import:
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tq="http://www.xmlportfolio.com/transquery"
xmlns:exsl="http://exslt.org/common"
xmlns:saxon="http://icl.com/saxon"
extension-element-prefixes="exsl saxon">
<xsl:param name="tq:input"/>
<!-- Apply templates in the tq:update mode to each
document in the TransQuery input collection -->
<xsl:template match="/">
<xsl:apply-templates select="$tq:input" mode="tq:update"/>
</xsl:template>
<!-- For each document in the TransQuery input
collection, create a new document with the
same name (effectively replacing it).
Recursively apply templates in the tq:update
mode to all descendants. -->
<xsl:template match="/" mode="tq:update">
<exsl:document href="{saxon:systemId()}">
<xsl:apply-templates mode="tq:update"/>
</exsl:document>
</xsl:template>
<!-- The default rule for all elements,
attributes, comments, PIs, and text
nodes is to copy the node as is
(and recursively apply templates to
children of elements). -->
<xsl:template match="@*|node()" mode="tq:update">
<xsl:copy>
<xsl:apply-templates select="@*|node()" mode="tq:update"/>
</xsl:copy>
</xsl:template>
</xsl:transform>
Then, an example update query could look like this (no extensions are
visible here):
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tq="http://www.xmlportfolio.com/transquery">
<xsl:import href="update.xsl"/>
<!-- Change the value of all attributes named
"paid" with value "yes", to "no". -->
<xsl:template match="@paid[.='yes']" mode="tq:update">
<xsl:attribute name="paid">no</xsl:attribute>
</xsl:template>
</xsl:transform>
Other examples can be borrowed from the XML:DB XUpdate project. In the end,
XUpdate may be more useful than XSLT as an XML update language. However, I
see some definite advantages in being able to use the same language (XSLT)
for both querying and updates.
XQuery 1.0 won't include updates, so we'll have to wait even longer for
anything on that front.
Finally, it might be possible to strip out the exsl:document part and define
the document-replacement semantics externally on the processing model level.
For example, an "update" query would "repeatedly apply this stylesheet to
every document in the database and replace the source document with the
result document." You might call this an "in-place transformation". This
would have the huge advantage that we could stick with pure XSLT 1.0 without
extensions. I would be interested in looking at what disadvantages there
would be with such an approach. One is that there would be a lot more magic
going on outside the XSLT (and outside the control of the query writer; then
again, maybe that's a good thing). Another is that certain kinds of update
queries that depend on cross-document information wouldn't be possible,
though I don't have an example in mind yet.
So what would this latter idea look like? Sticking with extension-free XSLT
is a goal that I don't want to give up on any time soon.
Still brainstorming,
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET