OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [docbook] Feedback on DocBook Transclusion proposal


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:jirka@kosek.cz]
> Sent: Wednesday, December 15, 2010 12:30 PM
> To: docbook@lists.oasis-open.org
> 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 (docbook@lists.oasis-open.org).
> 
> Thanks in advance,
> 
> 			Jirka Kosek
> 			on behalf of DocBook TC
> 
> 
> --
> ------------------------------------------------------------------
>   Jirka Kosek      e-mail: jirka@kosek.cz      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
> ------------------------------------------------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]