Re: [docbook] Re: alternative topic proposal

["Bob Stayton" <bobs@sagehill.net>]

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.