Re: Concatenating multiple input documents into a sing

I suspect I did a very poor job of explaining what I wanted... let's try 
again...

Basically what I'm trying to do is "expand" a RELAX-NG schema so that all of 
the includes are merged in-place into the main part of the schema.  If I 
understand your example correctly, what you're proposing would work for those 
includes that are in the main schema document, but includes that are nested 
inside other included documents would not get expanded.  It sounds like I  
can solve this problem by wrapping your solution (or something like it) in a 
template which selected on rng:include, e.g.: 

<xsl:template match="rng:include">
  <xsl:copy>
    <xsl:apply-templates select="document(@href)" />
  </xsl:copy>
</xsl:template>

This should include the content of each include, in document order.  BUT... if 
I do this, it looks like I'll get the <include> element in my output in 
addition to the content of the included document, e.g.: 

<include href="whatever.rng">
  ... content from included document
</include>

How would you suggest I avoid generating the enclosing <include> element?  Is 
there a better way to do this?


Cheers
Chris



On Wednesday 12 May 2004 08:45 am, David Carlisle wrote:
> > but I only get one node in the resulting variable
>
> In XSLT 1 if you use an xsl:variable with content then you don't get any
> nodes at all, you get a result tree fragment.
> If you use xsl:copy or an xx:node-set extension this result tree
> fragment will act like a node set with one node, a root node (/)
> that root node may have many children, in your case it will
> have children being the top level elements of each of the included
> documents.
>
> If you want to get a node set consisting of all the included documents
> then you can do
> <xsl:variable name="collection" select="document(//rng:include/@href)"/>
>
> as xsl:variable with a select expression doesn't generate an rtf.
>
> Note however that if you copy this secondd form to your output you will
> get the top level elements in an arbitrary order as node sets are
> unordered, unlike the first case where you get them in the order
> that the rng:include elements appear, as the children of the root node
> are ordered along the sibling axis.
>
> David