RE: Using XInclude with XSLT Transformations (fwd)

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...

Clark

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