[XSL-LIST Mailing List Archive Home]
Re: [xsl] XInclude in Cocoon
> > 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
Oh yes. I'm not pointing this out as an extraordinary problem. I agree that
flexibility is needed, but eventually (say in XSLT 1.1 final), there should be
some discussion of stylesheet behavior in the face of xincludes.
And I'mnot talking about a rigid specification, just notes. Maybe something to
the tune of
"The stylesheet processor may or may not resolve XInclude inclusions in the
Stylesheet infoset. If they are not resolved, they must be treated as literal
result elements. In order to create XInclude elements in the result tree, it
is advisable to use
<xsl:element name='xinclude:include' namespace='http://www.w3.org/1999/XML/xinc
To avoid different behavior in processors that do or do not resolve XIncludes."
> my 2 cents,
Not centimes? Too cheap, I suppose.
Uche Ogbuji Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list