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: Future DocBook: goals/requirements?


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

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.


PGP signature

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