RE: Ruminations on the future of DocBook

["Wills, Robert" <Robert.Wills@sts.co.uk>]

Norm,

Sorry, my previous posting was a bit vague - I agree that modelling element
instances or types as OO classes with a deep inheritance model is not
helpful in the DocBook problem domain. In my first implementation I had just
a pair of superclasses for an element and an element's type. Next time I
refactor I will probably refine this just a little to provide four
intermediate classes...

  blocks (e.g. <book>, <section>, <para>)
  inlines (e.g. <emphasis>, <xref>, <computeroutput>)
  metadata (e.g. <author>, <publisher>, <title>)
  text (i.e. character data)

...mainly so I can conveniently default whitespace handling and styling
behaviours. But beyond this I can't see any scope for useful inheritance
within a single DocBook schema.

What I am trying to set up for my development group is the ability to define
the grammar and styling for a whole set of related document types, e.g.
functional spec, technical spec, design note, use case model, installation
guide, user manual, FAQ, etc. by "deriving" them in a quite trivial way from
an "abstract" DocBook grammar and styling. This way we can put the work into
defining the corporate look and feel mostly in one set of files and
automatically keep the grammar and styling of all the derived document types
in sync as we make changes or upgrade to newer versions of DocBook. Under
the covers this is exactly the same process as customizing the DTD and
stylesheets, just using a different syntax more appropriate to my team. To
explain in more detail it would be best to look at code which is not
appropriate here.

The point about UML was really about communication and specification of
DocBook semantics at an abstract level not related to program code. As a
"techie" I spend a lot of time looking at and scribbling down both
analysis-level and design-level UML class diagrams and find the concepts
they include (e.g. aggregation and cardinality in associations) a natural
way to get clarity about certain aspects of a system. Having a few of these
available when I first came across DocBook would have enabled me to get to
grips with the big picture more quickly. I'm not sure what proportion of the
DocBook user community would share that position, though.

Thanks,
Rob.

-----Original Message-----
From: Norman Walsh [mailto:ndw@nwalsh.com]
Sent: 17 July 2003 20:37
To: Wills, Robert
Cc: docbook@lists.oasis-open.org
Subject: Re: Ruminations on the future of DocBook
[snip]
| I would like to use an object-oriented approach when dealing with DocBook
| grammars and instance documents, as OO concepts seem to fit the problem
| domain very well.

Uhm, I'm not inclined to agree about OO concepts and XML vocabularies.

  http://norman.walsh.name/2003/06/01/xmlnotoo

But providing UML or other useful representations certainly isn't off
the table.