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 (fragment context)


As mostly an aside on David's "declare the parent" statement,
editing "document fragments" in the "context" of the document
that (at other times) references them is an age old problem.

See OASIS (née SGML Open) Fragment interchange at
http://www.oasis-open.org/specs/tr9601.html

See W3C's work on XML Fragment Interchange at
http://www.w3.org/TR/NOTE-XML-FRAG-REQ and
http://www.w3.org/TR/2001/CR-xml-fragment-20010212
(never completed due to lack of interest).

paul

> -----Original Message-----
> From: Cramer, David W (David) [mailto:dcramer@motive.com]
> Sent: Monday, 2010 December 20 17:29
> To: Jirka Kosek; docbook@lists.oasis-open.org
> 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]