This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[docbook] Future DocBook: goals/requirements?


Norm,

Could you say something about the main goals or requirements behind the
changes you've in outlined in your 'Ruminations' articles ?

Is the aim mainly to make the vocabulary easier to maintain, or is it to
make it easier to use? Or just to bring some order and consistency to
the content models?

Looking at the classes of changes you outline in the articles
(rationalizing inlines, normalizing metadata, discarding cruft,
miscellaneous changes to simplify thing) and in your protoype, it seems
like it's more of a "cleaning up" and not really anything like the kinds
of more extensive refactorings that others have mentioned on the list
(e.g., splitting DocBook into a 'core' set of elements + modules for
different types of user needs).

That is, it's still one big schema of 300+ elements, with most of the
attribute values on those elements being the same as what they are
currently.

And when you say that your prototype is three-quarters finished, what's
the nature of the other one-quarter you'd do if you were to finish it?

You mention that the TC has talked many times about 'reworking the
parameter entities', but your current prototype isn't meant to be a
complete solution to that, right? In your Relax NG grammar, I see named
patterns for classes of inlines, but none yet for classes of divisions/
components/blocks -- and also not yet any definition-replacement hooks
that would facilitate customization of the schema.

  --Mike

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]