> -----Ursprungligt meddelande-----
> Från: Tom Bradford [mailto:[EMAIL PROTECTED]
> Skickat: den 24 september 2001 19:52
> Till: [EMAIL PROTECTED]
> Ämne: Re: XSelect thoughts and ramblings
>
>
> Gannholm Torbjörn wrote:
> > Sorry, Tom, I didn't understand what you were doing in your
> example, else I
> > would have rewritten that with xslt-like syntax.
>
> In the past couple of days, I've refined the syntax more, so
> the example
> would look like this:
>
> <x:query name="test" xmlns:x="http://www.xmldb.org/XUpdate";>
> <x:parameter name="id"/>
> <x:select col="/db/invoices" match="/[EMAIL PROTECTED]">
> <x:for match="products/product" action="replace">
> <x:variable name="id" match="@id"/>
> <x:select col="/db/products" match="/[EMAIL PROTECTED]" />
> </x:for>
> </x:select>
> </x:query>
OK, now I understand, thanks. With a more xslt-like syntax you would do
something like this (Actually, we should not use the xsl-namespace, since we
might wish to define the elements slighly differently, but the basic word
for doing something would win by being the same):
<x:template name="get-product-info">
<x:parameter name="id"/>
<x:copy-of select="/db/products/[EMAIL PROTECTED]"/>
</x:template>
<x:template name="create-invoice-node-set">
<x:parameter name="id"/>
<x:for-each select="/db/invoices/[EMAIL PROTECTED]">
<x:copy-of select=".">
<xupdate:modifications base=".">
<xupdate:replace select="products/product">
<x:call-template name="get-product-info">
<xsl:with-param name="id" select="@id"/>
</x:call-template>
</xupdate:replace>
</xupdate:modifications>
</x:copy-of>
</x:for-each>
</x:template>
Actually the above is not quite xslt, since in pure xslt the copy-of must be
empty. But xupdate commands should be able to be applied within it(!!). The
update is here done to our already created temporary node, not to the
database.
In pure xslt we would have to do a copy and an apply-templates instead of
doing a copy-of the invoice node. The advantage of apply-templates would be
that we could filter even more which information we would like to include in
one go. I can see that an <x:query> wrapper would be good to restrict the
scope of the templates, though.
<xsl:template name="get-product-info">
<xsl:parameter name="id"/>
<x:copy-of select="/db/products/[EMAIL PROTECTED]"/>
</xsl:template>
<xsl:template name="create-invoice-node-set">
<xsl:parameter name="id"/>
<xsl:for-each select="/db/invoices/[EMAIL PROTECTED]">
<xsl:copy>
<xsl:apply-templates select="@* | * | text() | etc."/>
</xsl:copy>
</xsl:for-each>
</xsl:template>
<xsl:template match="products/product">
<xsl:call-template name="get-product-info">
<xsl:with-param name="id" select="@id"/>
</xsl:call-template>
</xsl:template>
<xsl:template match="products">
<xsl:copy>
<xsl:apply-templates select="@* | * | text() etc."/>
</xsl:copy>
</xsl:template>
<xsl:template match="@* | * | text() | comment() etc."/>
<xsl:copy-of select="."/>
</xsl:template>
Then to actually set a variable to hold our derived node-set in an xslt-like
way we would in both cases above do something like:
<x:variable name="my-filled-out-invoice">
<x:call-template name="create-invoice-node-set">
<x:with-param name="id" select="12345"/>
</x:call-template>
</x:variable>
>
> The query element is simply the wrapper.
As I said above, a wrapper is a good idea. Perhaps this is the only element
above xslt that would really need to be defined to have a very powerful
query-language for generating a result node-set.
Perhaps one should have a result-tag also inside the query-tag to define
where one starts to build the result.
>
> The parameter element establish a parameter context.
> Parameters must be
> provided by the calling context. The original example had an error in
> it... parameters can't have values in the query itself.
>
> The first select is the top level select. From the collection
> /db/invoices, retrieve all invoice documents that have an id attribute
> of the value provided in the parameter id.
>
> The for element says for each document returned, replace all produce
> elements under the products element.
>
> The variable element says to create a scoped variable called id, and
> assign the value of the product's id element to it.
>
> The sub select pulls in all documents from the collection /db/products
> that have an id attribute whose value is equal to the value of the id
> variable.
>
> A resulting document might like like this:
>
> <invoice id="12345">
> <header>
> <customer id="9543"/>
> <address ship-to="9543-1"/>
> <address bill-to="9543-2"/>
> </header>
> <products>
> <product id="10001">
> <name>Nerf Cannon</name>
> <description>A Nerf death cannon</description>
> <price type="usd">39.99</price>
> </product>
> <product id="10009">
> <name>Nerf Cannon Ammo</name>
> <description>Ammo for the Nerf death cannon</description>
> <price type="usd">8.99</price>
> </product>
> </product>
> </invoice>
>
> In a real invoice, you'd never want to include the actual product
> information... This would let you perform a query that expands it for
> external processing. Obviously, you can define a more complex query
> that expands the customer, and address records. The point in
> XSelect is
> not to transform documents, but to easily link/expand them.
>
> --
> Tom Bradford The dbXML Group, L.L.C. http://www.dbxmlgroup.com/
> Desktop, Laptop, Settop, Palmtop. Can your XML database do that?
> ----------------------------------------------------------------------
> Post a message: mailto:[EMAIL PROTECTED]
> Unsubscribe:
> mailto:[EMAIL PROTECTED]
> Contact administrator: mailto:[EMAIL PROTECTED]
> Read archived messages: http://archive.xmldb.org/
> ----------------------------------------------------------------------
>
----------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
