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] questions about the future of docbook (ng)...


I find myself agreeing with the points made below.

See my posting from last year on docbook.org/wiki:

***
An alternative, modular design could make docbook available in smaller 
chunks targeted towards specific usages/users (e.g. those writing 
articles vs specifications vs faq). Such a design would have several 
important benefits, such as obviating the need for simplified docbook 
(freeing up resources currently tied up in maintaining this product and 
keeping it in synch with full docbook), making docbook simpler to 
understand and more accessible, and providing a natural set of fault 
lines for organizing tutorials and documentation. ModularDocbook 
<http://www.docbook.org/wiki/moin.cgi/ModularDocbook>:http://www.docbook.org/wiki/moin.cgi/ModularDocbook
***

In a nutshell, you would have a relatively small "core" set of 
constructs, and then each dialect/usage
(such as article, book, review, resume, business letter, journal entry, 
meeting minutes, role description, design pattern,
slideshow presentation, brochure, etc. etc) would be defined by its own 
stand-alone schema/DTD files which
would *include* the appropriate core pieces.

This would nudge docbook a little bit more towards something like OASIS 
Universal Business Language, in fact
it could complement it quite nicely.    I could see it expanding where 
you would have a small team (Norm et al)
in charge of the core and different comittees or open source-style 
groups for each logical area (a la SlideML).

The modular nature of this approach means that, even if I *didn't* like 
the "docbook resume markup", all I have
to do is make my own resume.dtd but it still includes all the same core 
docbook DTDs and therefore
is largely compatible with the larger docbook universe.

I believe this design would give you have compatibility when/where you
want it without lockin to a giant monolithic structure.

my 2c,

--Craeg Strong

Stefan Seefeld wrote:

> hi there,
>
> I was tempted to write another 'talkback' to Norm's
> blog (http://norman.walsh.name/2004/01/01/absinthe)
> but I believe this ML is a better medium for a followup...
>
> What I'm trying to understand is how docbook ng will
> deal with the proliferation of domain-specific vocabularies.
>
> One obvious option is modularization, though it isn't (to
> me at least) clear how exactly that would be designed.
>
> What I thought of as modularization isn't merely a way
> to *use* subsets of the docbook vocabulary, but to really
> redefine it so there is a 'core' vocabulary and a set of
> 'profiles'.
>
> IMO the question should be asked 'what is docbook' ?
> Is 'classsynopsis' part of it ? Or is it part of a profile ?
> Can people add domain-specific vocabularies (profiles)
> without the need for a central authority ? Etc.
>
> I'm tempted to use docbook in a couple of domains I'm
> writing documentation in (notably software architecture /
> development process, modeling, API documentation, etc.),
> and I feel some higher level vocabulary missing.
>
> On the other hand I totally agree with Norm's assessment
> that docbook isn't a modeling language. But the, wouldn't
> there be a way to *add* a modeling language on top of
> docbook ? Or somehow map one to the other ?
> I'm for example playing with UML modeling tools that let
> me generate 'html reports' from my models. These are
> generated via xslt scripts, so it is tempting to try to
> write new scripts that generate some docbook vocabulary...
>
> What do you think ?
>
> Kind regards,
>         Stefan




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