Re: [docbook] [dbx g2] using modules; version attribute

[Bob Stayton <bobs@sco.com>]

On Thu, Jun 19, 2003 at 10:38:36AM +0200, Tobias Reif wrote:
> [DocBook XML generation 2]
> 
> Hi
> 
> Just to thoughts:
> 
> * Modules, Subsets
> 
> I just heard from a project in a University that they switched away from 
> DocBook. The said the language and the related tools are too large.

I'd be curious to know what the circumstances were.
I'm quite sure there are many projects for which
DocBook is not a good fit.  That doesn't mean there
is something inherently wrong with DocBook.
 
> It would be great if it would be *very* simple to specify a set of 
> modules, so that authors and tools can state in one simple line which 
> modules they use respectively support.
> 
> Eg as in
> http://thaiopensource.com/relaxng/xhtml/xhtml-strict.rng :
> 
> <grammar ns="http://www.w3.org/1999/xhtml"
>           xmlns="http://relaxng.org/ns/structure/1.0">
> 
>    <include href="modules/datatypes.rng"/>
>    <include href="modules/attribs.rng"/>
>    <include href="modules/struct.rng"/>
>    <include href="modules/text.rng"/>
>    <include href="modules/hypertext.rng"/>
>    <!-- ... -->
> </grammar>

I would agree that if modularization becomes an option,
then it must be easy to use.  My concern with schema modules
is that it could make things more complex.  Currently
you can specify a single DTD and everyone knows
what's in it, and the tools know what they have to deal
with.  A single DTD may be big, but it is simpler than handling
multiple possible combinations of modules.
 
> 
> * Required Version Atribute
> 
> It would be great if the new DocBook would have a required version 
> attribute on the root element. This in addition to the namespace will 
> make it easier for tools to find out what they are dealing with. (XSLT 
> has a version attribute, SVG versions higher than 1.0 require one, etc)

Can you clarify what this version attribute contains?
Version of the schema?  Is this intended as a replacement
for a DOCTYPE declaration?  Would this try to capture the
combinations of modules used in the current document?


-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com