RE: [docbook] Transclusion

["David Cramer" <dcramer@motive.com>]

4. Validation. The author needs a way to know if the document is still
going to be valid post-transclusion. 

David

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com] 
> Sent: Friday, December 11, 2009 3:17 PM
> To: docbook@lists.oasis-open.org
> Subject: [docbook] Transclusion
> 
> Hello world,
> 
> There's an open RFE about transclusion
> 
>   
> http://sourceforge.net/tracker/?func=detail&aid=2820947&group_
id=21935&atid=384107
> 
> The TC's initial position was to push back, suggesting that 
> the right technology for the task is XInclude.
> 
> Unforunately, XInclude isn't a complete solution because 
> getting the content transcluded doesn't solve the entire 
> problem. And it doesn't help that the the standardized 
> XPointer schemes are fairly brittle.
> 
> The TC would like to collect a set of use cases and 
> requirements for transclusion. Here are the requirements that 
> I can think of (with help From the comments in the REF).
> 
> 1. Transclusion can introduce duplicate xml:id values. It 
> should be possible to specify a strategy for changing xml:id 
> values in the transcluded content so that this is not the case.
> 
> 2. Using the XInclude framework and element schemes, it's 
> only possible to transclude a single element. It should be 
> possible to specify ranges, at least ranges of sibling elements.
> 
> 3. The XInclude framework and element schems are a little bit brittle.
> Are there more robust schemes that we could encourage 
> implementors to support?
> 
> What other requirements are there?
> 
>                                         Be seeing you,
>                                           norm
> 
> -- 
> Norman Walsh <ndw@nwalsh.com>      | Wink at small faults; 
> for thou has
> http://www.oasis-open.org/docbook/ | great ones.--Thomas 
> Fuller (II) Chair, DocBook Technical Committee |
>