Ok, I'm still studying the proposal, but I want to say I've felt the pain of 
the problems it seeks to solve and am looking forward to using this someday. We 
have a homegrown transclusion mechanism (which we called 'holmanization' since 
it was Ken Holman who originally explained to me how to pull it off) that we 
created almost nine years ago. We're finally partially retiring it in favor of 
xincludes, but still need to use it for cases where using an xinclude would 
result in duplicate ids. We're also moving away from entities and need 
something to replace those, so I think all of this is great. 

So far I have one question:

We hope that editor vendors will support this and will show what the value that 
<ref name="productname"/> would resolve to in the way they currently do for 
entities. If you have a book.xml and several chapter-n.xml files and perhaps 
even some smaller reused fragments like note.xml, all of which are pulled into 
the book.xml file using either the new <ref fileref="chapter-1.xml"/> markup or 
an xinclude, when you process the chapter.xml or note.xml file (say by opening 
it in an editor) there's no way to know what definitions to use for any <ref 
name="productname"/> elements. 

Should there be some way to declare the parent file to use so that the 
application will know where to start looking for definitions? Something like 
the following emacs+psgml mode markup (but ideally not relying on markup 
embedded in comments):

      <!--
       Local Variables:
       sgml-parent-document: ("top.xml" "book" "sect1")
       End:
      -->

Otherwise, you're faced with only opening the fragments via their parents or 
adding editor/application-specific markup so it will know what parent doc to 
use if the fragment is processed/edited independently.

I'll keep reading. The id fixup stuff looks very interesting too. 

Thanks,
David 

> -----Original Message-----
> From: Jirka Kosek [mailto:[email protected]]
> Sent: Wednesday, December 15, 2010 12:30 PM
> To: [email protected]
> Subject: [docbook] Feedback on DocBook Transclusion proposal
> 
> Hi,
> 
> during last few months DocBook TC spent serious time discussing and
> working on solution for the following RFE (Ability to transclude text):
> 
> http://sourceforge.net/tracker/?func=detail&aid=2820947&group_id=21935&;
> atid=384107
> 
> As a part of this process we gathered set of requirements for
> transclusion mechanism which is available at:
> 
> http://docbook.org/docs/transclusion-requirements/
> 
> Also DocBook TC created proposal which tries to resolve problems
> mentioned in the original RFE together with some additional
> requirements that appeared along the way:
> 
> http://docbook.org/docs/transclusion/
> 
> At this stage DocBook TC is looking forward for feedback from DocBook
> users and from implementers of DocBook tools. Our concern is that
> although some proposed features are very useful they may be too complex
> to gain broad adoption between implementers.
> 
> Any comments and feedback are more then welcomed. Please direct it
> directly to this mailing list ([email protected]).
> 
> Thanks in advance,
> 
>                       Jirka Kosek
>                       on behalf of DocBook TC
> 
> 
> --
> ------------------------------------------------------------------
>   Jirka Kosek      e-mail: [email protected]      http://xmlguru.cz
> ------------------------------------------------------------------
>        Professional XML consulting and training services
>   DocBook customization, custom XSLT/XSL-FO document processing
> ------------------------------------------------------------------
>  OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
> ------------------------------------------------------------------

Reply via email to