Re: formal objects in docbook 5

[Norman Walsh <ndw@nwalsh.com>]

/ Stefan Seefeld <seefeld@sympatico.ca> was heard to say:
| I didn't find the tools I have seen so far satisfying at all, and so I'm
| wondering what it would take to reimplement it. As I said, for me 'requirement'
| is merely a markup on top of the existing docbook vocabulary. No structural
| constraints (or almost) as to what a requirement should look like (that's
| best left up to the people who would work with the tool).
| All I need is a way to track requirements, i.e. track their versions, perform
| some validation, etc.

In DocBook 5, you'll be able to use <info> in a lot more places, so
it's possible that you could do it with the role attribute and some
appropriate metadata.

| Ah well, I had hoped that docbook ng becomes more easy to extend, and thus
| the famous 'role' attribute would be slowly phased out.

The advantage of the role attribute is that you don't have to change
the stylesheets or editing tools. If you're happy to write your own
stylesheet customizations, adding a 'requirement' as a peer to
paragraph would be dead easy:

  include "docbook.rnc"

  db.para.blocks |= my.requirement

  my.requirement = element requirement {
     db.para.attlist,
     db.para.info,
     (db.all.inlines | db.nopara.blocks)*
  }

| PS: FWIW, I find the 'readyset' project at http://readyset.tigris.org/
|      quite intriguing, but I think it should be done with docbook, not
|      xhtml :-)

I'm hardly likely to disagree :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | There are no wise few. Every
http://www.oasis-open.org/docbook/ | aristocracy that has ever existed
Chair, DocBook Technical Committee | has behaved, in all essential
                                   | points, exactly like a small
                                   | mob.--G. K. Chesterton

PGP signature