[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Ruminations on the future of DocBook
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:email@example.com] Sent: 17 July 2003 20:37 To: Wills, Robert Cc: firstname.lastname@example.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.