W3C home > Mailing lists > Public > www-xml-xinclude-comments@w3.org > July 2000

RE: Using XInclude with XSLT Transformations (fwd)

From: Clark C. Evans <cce@clarkevans.com>
Date: Thu, 20 Jul 2000 18:00:22 -0400 (EDT)
To: Jonathan Marsh <jmarsh@microsoft.com>
cc: "'www-xml-xinclude-comments@w3.org'" <www-xml-xinclude-comments@w3.org>
Message-ID: <Pine.LNX.4.10.10007201737150.6786-100000@clarkevans.com>

Let me try and patch up your questions/concerns.

On Thu, 20 Jul 2000, Jonathan Marsh wrote:
> 3) The default view is that the included tree is not 
>    transparent to inclusion.

How about "xinclude:strip-after-include" where the default 
value is 'default'?  (just like the xml:space attribute?)
> I prefer something like an infoset addition that provides
> pre-inclusion information for those processors sophisticated 
> enough to expose it. 

Yes, but this would cause yet-another dependency between
specifications.  If a new axis was added to the infoset, 
then XSLT would have be modified, etc.  Yuck.

> The simplest processors would still be completely transparent.

Yes, this is the goal.  However, the primary advantage of
XInclude over Entities, as I see it, is that it uses the
XML syntax -- so that processors like XSLT can be aware of them.

As far as transparency is concerned, this is what 
namespaces are tasked with solving!  no? 

> 1) What if I include an empty element?

Hmm.  How about "xinclude:state" which can take on the values:
 active    - processors should include when this is set (the default)
 included  - the inclusion has already occurred (only when strip='false')
 inactive  - skip inclusion for now... (good for XSLT)

> 2) Merging attribute lists looks like a significant complication.

Yes, kinda ugly.  However, I really *do* like the idea.  It provides
for inheritance of sorts.  But, it might not be worth the complexity.

> I agree that it seems wrong to throw out the user's element and all its
> attributes and even content just because of the presence of a couple of
> attributes.  I am leaning back toward the element syntax of a previous draft
> for this reason among others.

Yes, it just kinda feels wrong.

Hope this helps...

Received on Thursday, 20 July 2000 17:48:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:29 UTC