RE: Using XInclude with XSLT Transformations (fwd)

I don't actually see how this is supposed to work.

1) What if I include an empty element?
2) Merging attribute lists looks like a significant complication.
3) The default view is that the included tree is not transparent to
inclusion.  I prefer something like an infoset addition that provides
pre-inclusion information for those processors sophisticated enough to
expose it.  The simplest processors would still be completely transparent.

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.

> From: Clark C. Evans <clark.evans@softwareag-usa.com>

> On Thu, May 18 2000 Jonathan Marsh wrote:
> | The original goal was for XInclude to be transparent. 
> | Your comment fuels my suspicion that this may not be the
> | best direction.
> 
> I also concur with Eric van der Vlist's post [1] -- having 
> XInclude information available to XSLT would indeed
> be a very large improvement.   Following is a straw-man 
> suggestion for allowing tighter XSLT integration without 
> requiring a modification to XPath.
> 
> Suggestion:  Only apply the "inclusion" process when
>              the destination element is <empty/>, etc.
> 
> This suggestion creates a fixed-point so that the 
> inclusion process applied to the same text
> a second time will be a no-op.
> 
> ...
> 
> source.xml
> 
>   <foo>
>     <bar xinclude:href="include.xml#xptr(b)" one="1" />
>   </foo>
> 
> include.xml
>   
>   <a>
>     <b two="2" one="3" >
>       some <br/> content
>     </b>
>   </a>
> 
>   ==> Apply "inclusion" process to source.xml
> 
> 
> result.xml
> 
>   <foo>
>     <bar xinclude:href="include.xml#xptr(b)" one="1" two="2" >
>       some <br> content
>     </bar>
>   </foo>     
> 
> 
>   ==> Apply "inclusion" process to result.xml to make result2.xml
> 
> result2.xml
> 
>   <foo>
>     <bar xinclude:href="include.xml#xptr(b)" one="1" two="2" >
>       some <br> content
>     </bar>
>   </foo>
> 
> 
> ...
> 
> This slightly-different behavior makes allows the include 
> specification to work othogonally with other specifications
> without change...
> 
> ...
> 
> The primary problem as I see it is, how does one deal with
> attributes?  
> 
> An obvious solution is to copy over attributes that
> do not already have values -- think inheritance.
> However, this may cause questions for XSLT as to which
> attributes were copied and which were already specified.
> 
> This quirk can be overcome if the xlink process somehow
> preserves this information, perhaps by appending an
> additional attribute detailing which attributes were copied.
> 
>   <foo>
>     <bar xinclude:href="include.xml#xptr(b)" one="1" two="2" 
>          xinclude:copied="two" >
>       some <br> content 
>     </bar>
>   </foo>
> 
> 
> Hope this helps,
> 
> Clark Evans
> 
> 
> References:
> [1] 
> http://lists.w3.org/Archives/Public/www-xml-xinclude-comments/
2000May/0001.html

Received on Thursday, 20 July 2000 16:35:01 UTC