RE: auto/embed is not node transclusion

Paul Prescod wrote:

>
> Now let demonstrate that XLink does not provide transclusion. First, it
> does not specify a data model for the result of a transformation. Second,
> the things it links to are not restricted to XML elements. In other words,
> XLink can embed JPEGs, MPEGs and other data that does not have a concept
> of nodes (unless we import the ISO concept of groves and property sets for
> them). Therefore we *cannot* in general interpret the grove mode in terms
> of a grove to grove transformation.

	This is an excellent point. In XSLT 6.2.2 the issue of doc(uri) pointing to
something other than an XML node is noted as an unresolved editorial point.

>
> You could argue that I am being a purist. Embedding PDFs or JPEGs would
> "probably" have the behavior of just *displaying* them inline but
> embedding an XML element would have the behavior of node-level
> transcluding it. Browsers would "probably" implement it compatibly.

	Would links to binary resources have the same status as NOTATION's in terms
of the XML information set? A set of notations could map to the returned
content-type and a browser would deal with such a 'notation' in the same
mechanism that a MIME content-type is dealt with (e.g. in-line, plug-in
etc).

>
> I am not very confident of interoperable implementations by the major
> browser vendors. Personally, I feel that I would rather wait for a real
> transclusion mechanism even if it means I have to wait for a W3C grove
> model and addressing mechanism that can differentiate a reference to an
> input document from a reference to the result document.

	Or, we can adopt the ISO grove model once the XML property set/information
set is defined. Is there any reason to reinvent the wheel in terms of
groves?

Jonathan Borden
http://jabr.ne.mediaone.net


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