W3C home > Mailing lists > Public > public-grddl-wg@w3.org > October 2006

Re: XInclude Open Issue

From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
Date: Fri, 20 Oct 2006 13:37:46 -0400 (EDT)
To: GRDDL Working Group <public-grddl-wg@w3.org>
Message-ID: <Pine.GSO.4.60.0610201329530.16098@joplin.bio.ri.ccf.org>

Ugh.. an XSLT extension-based implementation of XInclude - which relies 
on exsl:function no less.  Not very portable.  My thoughts 
are that it doesn't address the issue since the solution is XSLT 
implementation dependent.  If the spec is meant to give guidance on this 
sort of thing I would think it would make better sense to propose that 
in the absense of a pipeline language, the implementation can do 
what it wishes (some implementations *will* be able to resolve XIncludes 
without prompting, *before* applying an XSLT transform).  Otherwise, a 
pipeline can be explicit about the XML processing.

Consider an XML parser and XSLT implementation that already handles 
XInclusion by default, explicitely implementing the XInclude resolution in 
this way would clash with such a scenario as there will be no way for the 
nominated transform to determine if the XIncludes had been expanded 
already.


On Fri, 20 Oct 2006, Murray Maloney wrote:

> I understood that one could not do XInclude processing in an XSLT 
> Transformation.
> I received this pointer from a member of the XML Proc WG. Does this address
> the open issue?
>
>
> http://www.dpawson.co.uk/xsl/sect2/include.html#d11058e170

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org
Received on Friday, 20 October 2006 17:38:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:46 GMT