Re: [xsl] XInclude in Cocoon

[Daniel Veillard <Daniel.Veillard@xxxxxxx>]

On Thu, Feb 08, 2001 at 03:32:49PM -0700, Uche Ogbuji wrote:
> > But thinking about it, isn't there an interesting issue with
> > XIncludes in XSLT? If an XSLT processor is presented with:
> > 
> > <xsl:template match="/">
> >    <foo>
> >       <xinclude:include href="foo.xml" />
> >    </foo>
> > </xsl:template>
> > 
> > How does the processor know whether the xinclude:include should be
> > activated during the parse of the XSLT stylesheet or whether the
> > include element should be copied to the result tree?
> 
> This is defined by the processor itself.
> 
> The XInclude spec defines a way to express inclusions, but makes no 
> prescriptions of the semantics of such inclusions.  An XSLT processor can 
> choose to expand the include or pass it on, and in both cases be conformant to 
> XInclude and XSLT.
> 
> Yes, this could eb problematic for interoperability.
> 
> > >From the sounds of XInclude, I guess that processing the include
> > elements is a pretty low-level feature of an XML processor, and that
> > the stylesheet's DOM will include the external file.
> 
> Not necessarily.  The only note that is made is that it is at a higher level 
> than parsing.  But other than that, it could be at a level below DOM, between 
> DOM and XSLT, or above XSLT.

  Agreed, Xinclude is defined as an operation on Infoset, i.e. parser
results. Nothing is said about when it should be applied. Honnestly,
I doubt that one way would fit everybody's need. And as far
as I can tell toolkits providing XInclude functionnality have 2 operating
APIs:
      - the option of having Xinclude processed directly at parse time
      - a function allowing to process XInclude a posteriory at any time
        in the life of the document (assuming your document have a DOM
	like tree representation with enough informations to process XInclude).

  In the case of Xinclude/XSLT, I would in general apply XInclude first,
because it's likely:
      - it avoid too much troubles resolving URI references to the
        included fragment, which can be nasty on an XSLT result (which
	have no Base URI).
      - to be more efficient since preprocessing of the include is done
        only once per template instead of once per result instance

> > Which means that to *create* an include element in the result, you'd
> > have to use the xsl:element instruction *or* use a namespace alias. In
> > other words, elements and attributes that are dealt with by low-level
> > XML processors have to be generated with the same techniques as XSLT
> > elements and attributes. As XLink becomes supported as well,
> > presumably we'll run into the same issues there.
> 
> I think you pretty much bring up an undefined crease between the 
> specifications.  There are many others.
> 
> This is what we get until the XML core specs settle down.

  Well, not that simple, sometimes you just don't want to define
in a rigid way how processing have to be done, especially when all this
are actually new sections of a tool box. It sometimes does make sense
to process first A then B, and in other cases B then A, B and A being
in the pool:
   - XLink
   - Schemas validation
   - XSLT
   - XInclude
   - XML Canonicalization
   - etc...
  Even when existing spec defines the processing rigidly like DtD validation
well the toolkit sometimes need more flexibility (people do want to 
validate a parsed and modified document without necessarilly going back to
serialization).

  my 2 cents,

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@xxxxxxxxxx  | libxml Gnome XML toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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