From: Chris Bayes (chris@bayes.co.uk)
Date: Mon Dec 31 2001 - 11:33:41 CET
I added tq:baseURI(.) and tq:document(uri, $doc) functions to
http://www.bayes.co.uk/xml/index.xml?/xml/utils/transquery/transquery.xm
l As you can only extend msxml with functions you have to use it like
<xsl:variable name="doc">
<xsl:apply-templates />
</xsl:variable>
<xsl:value-of select="tq:document('db/newdoc.xml', $doc)" />
Or
<xsl:value-of select="tq:document(tq:baseURI(.), $doc)" />
Instead of say
<xsl:template match="/" mode="tq:update">
<exsl:document href="{saxon:systemId()}">
<xsl:apply-templates mode="tq:update"/>
</exsl:document>
</xsl:template>
tq:document returns an empty string. I put them in the tq namespace
because this primative document function wouldn't be considered for
exslt ;-) but it is there just to play with. There is no error checking
on the xml.save so the db obviously must be writable.
I also removed the -e option because 1. it isn't needed with the baseURI
function. 2. because of the way this implementation works you can get
the info from tq:database using tq:baseURI(.) I haven't had time to give
it a good testing so there might be the odd bug. If you are doing a pure
update transform then there will be no output doc so you will get an
error
D:\MyProjects\transquery>cscript transquery.js -db db -s baseuri.xsl -o
tmp.xml -f .xml Microsoft (R) Windows Script Host Version 5.6 Copyright
(C) Microsoft Corporation 1996-2001. All rights reserved.
XML document must have a top level element.
: -1072896680
Initial Transform Error.
^
line 0
Because the output doc is empty. I'll fix that next year. For the time
being just make sure that there is a result or live with the error.
Happy New Year Chris
XML/XSL Portal
http://www.bayes.co.uk/xml
> 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