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] alternative topic proposal


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sounds really appealing.
Can we imagine one could topicref DITA modules as well?
This would allow to have a contentmap reference topics authored in both
DITA and DocBook.

It would just require to have "real" namespace aware stylesheets right?

Camille.

Jirka Kosek a écrit :
> Bob Stayton wrote:
> 
>> I think this is a simple and elegant way to create modular content
>> using familiar DocBook elements and two new elements,
>> topic and topicref.
> 
> I quite like your proposal, but I think that we can go even further and
> completely decouple pieces of modular content from assembly information.
> This feature was already implemented in website and it will allow us to
> create interoperable format used for customized chunking ($chunk.toc
> parameter in the stylesheets).
> 
> You will create set of small modules -- it is almost irrelevant whether
> they will use section, topic, article or whatever as their root element.
> They you will have contentmap element which will be used to assemble
> content into right order and nesting. For example:
> 
> <contentmap>
>   <topicref href="XMLCatalogs.xml">
>    <topicref  href="WhyUseXMLCatalogs.xml"/>
>    <topicref  href="HowToWriteCatalogs.xml">
>        <topicref  href="ResolveDTDLocation.xml"/>
>        <topicref  href="LocateXSLstylesheet.xml"/>
>        <topicref  href="MapWebAddress.xml"/>
>        <topicref  href="MapWithRewrite.xml"/>
>        <topicref  href="MultipleCatalogs.xml"/>
>    </topicref>
>    <topicref  href="ExampleDocBookCatalog.xml"/>
>    <topiciref  href="HowToUseCatalog.xml">
>        <topicref  href="InSaxon.xml"/>
>        <topicref  href="InXalan.xml"/>
>        <topicref  href="InXsltproc.xml"/>
>    </topicref>
>   </topicref>
> </contentmap>
> 
> To make this more flexible we can add renderas attribute to map this
> structure to already existing processing model:
> 
> <contentmap>
>   <topicref href="XMLCatalogs.xml" renderas="chapter">
>    <topicref  href="WhyUseXMLCatalogs.xml" renderas="sect1"/> <!-- this
> would be default value of renderas under chapter -->
>    <topicref  href="HowToWriteCatalogs.xml">
>        <topicref  href="ResolveDTDLocation.xml"/>
>        <topicref  href="LocateXSLstylesheet.xml"/>
>        <topicref  href="MapWebAddress.xml"/>
>        <topicref  href="MapWithRewrite.xml"/>
>        <topicref  href="MultipleCatalogs.xml"/>
>    </topicref>
>    <topicref  href="ExampleDocBookCatalog.xml"/>
>    <topiciref  href="HowToUseCatalog.xml">
>        <topicref  href="InSaxon.xml"/>
>        <topicref  href="InXalan.xml"/>
>        <topicref  href="InXsltproc.xml"/>
>    </topicref>
>    <topicref href="biblio.xml" renderas="bibliography"/>
>   </topicref>
> </contentmap>
> 
> The default behaviour could be either that renderas is inferred from
> root element of referenced module (if we will not use topic element for
> modules) or must be specified manually at least on root topicref and
> rendering of nested topicref could be inferred (e.g. topicrefs inside
> <topicref renderas="chapter"/> will be treated as sect1).
> 
> And finally we can add more attributes for controlling chunking.
> 
> <contentmap>
>   <topicref href="XMLCatalogs.xml" outputchunk="XMLCatalogs.html">
>    <topicref  href="WhyUseXMLCatalogs.xml">
>    <topicref  href="HowToWriteCatalogs.xml" outputchunk="HowTo.html">
>        <topicref  href="ResolveDTDLocation.xml"/>
>        <topicref  href="LocateXSLstylesheet.xml"/>
>        <topicref  href="MapWebAddress.xml"/>
>        <topicref  href="MapWithRewrite.xml"/>
>        <topicref  href="MultipleCatalogs.xml"/>
>    </topicref>
>    <topicref  href="ExampleDocBookCatalog.xml" outputchunk="..."/>
>    <topiciref  href="HowToUseCatalog.xml"  outputchunk="...">
>        <topicref  href="InSaxon.xml" outputchunk="..."/>
>        <topicref  href="InXalan.xml" outputchunk="..."/>
>        <topicref  href="InXsltproc.xml" outputchunk="..."/>
>    </topicref>
>   </topicref>
> </contentmap>
> 
> New elements contentmap and topicref will not be part of DocBook schema
> but they will be defined in a completely separate schema for
> contentmaps. We could eventually add also topic element into DocBook
> schema. But such element will be allowed only as a root element
> (couldn't be child of any other element) and its content have to be
> discussed more carefully, but I think that it should be very similar to
> section. That way only one new element topic would be added into DocBook
> schema and this addition wouldn't change any existing content model.
> 
> This solution is also able to respond to RFE about having section and
> task on the same level as siblings. You can freely reference sections
> and tasks from content map.
> 
> This approach would cause only very conservative change in DocBook
> schema, but at the same time it will address I hope all new requests for
> more modular and topic-like authoring.
> 
>                 Jirka
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFFR2lcjv9P65BfOUMRAviPAJ401WGNUzWl82nVMmx+fm6qefPwOQCfeWpE
46SYmXRXfFPm6M/+Z2Np2hg=
=42Yo
-----END PGP SIGNATURE-----
begin:vcard
fn;quoted-printable:Camille B=C3=A9gnis
n;quoted-printable:B=C3=A9gnis;Camille
org:NeoDoc
adr:Domaine du petit Arbois BP 88;;CEEI;Aix en Provence Cedex 4;;13545;France
email;internet:camille@neodoc.biz
tel;work:+33.4.42.22.62.35 
tel;cell:+33.6.33.15.10.23
note;quoted-printable:Rejoignez mon r=C3=A9seau sur viaduc:=0D=0A=
	=0D=0A=
	http://www.viaduc.com/invitationpersonnelle/002lm14bc0jlkfk
x-mozilla-html:FALSE
url:http://neodoc.biz
version:2.1
end:vcard



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