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:]
> Sent: Friday, December 11, 2009 3:17 PM
> To:
> 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 <> | Wink at small faults;
> for thou has
> http://www.oasis-open.org/docbook/ | great ones.--Thomas
> Fuller (II) Chair, DocBook Technical Committee |
>
