[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Re: alternative topic proposal
Keep reading. 8^) The idea of a contentmap of existing elements is essentially what Jirka's proposal is. It could be implemented outside of the DocBook schema initially. Bob Stayton Sagehill Enterprises DocBook Consulting bobs@sagehill.net ----- Original Message ----- From: "Norman Walsh" <ndw@nwalsh.com> To: <docbook@lists.oasis-open.org> Sent: Wednesday, February 21, 2007 10:43 AM Subject: [docbook] Re: alternative topic proposal / "Bob Stayton" <bobs@sagehill.net> was heard to say: | If we also introduce the idea of topicref, then we are adding new | capabilities to DocBook to assemble these modules into sequences and | hierarchies. The difference from XInclude is that a topicref is | resolved by an XSLT process, so the assembly process can actively | filter and fix content rather than just copy it into place. That's a | big gain in modular processing, if you need it. Two points: 1. I'd rather not reinvent XInclude. 2. I think it's a mistake for the TC to assume any particular kind of processor will be used to implement the processing expectations of DocBook. | If we were just adding topic and making it like article, then I would | agree that it isn't much of a gain over article. But including the | capability of smart assembly adds considerable power to the system if | you are writing in a modular fashion. If you are not doing modular | writing, then this change should have no effect on your current | practices. That suggests to me that we don't need any new elements at all, we just need some concept of a map. It further strikes me that it might make more sense to wait until three or four or ten of them have been invented before we try to do any standardization.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]