OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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

Subject: Re: [docbook-tc] XML Policy?

On Thu, Dec 06, 2001 at 02:37:23PM -0800, Norman Walsh wrote:
> At one time, we decided to abandon SGML. Later, in Philadelphia I
> think, we reversed that decision and decided we'd keep SGML support as
> a customization layer on the XML DTD. In the last few weeks, I've been
> asked about a number of practical issues that really make me uneasy.
> Consider:
> - xml:lang
> - xml:space
> - XML Base
> - XML Include
> Supporting these in XML DTDs is hard, and it's going to start to look
> ugly in SGML. And we really need to consider moving to another schema
> language, I think.
> Comments?

You are asking two big questions here: diverging DocBook XML
from SGML, and replacing DTDs with some XML schema.

On the first question,
I don't believe we can maintain complete compatibility
between the SGML and XML DTDs.  That would mean DocBook
would always be held back by the limitations of SGML,
which XML was supposed to overcome, if you recall.

I believe we should focus on the new features that the
DocBook community feels it wants and needs, not necessarily
the new technologies.  Where possible, implement new
features without introducing new XML technologies.  Where a
new XML technology enables a desirable new feature that we
can't get without it, then we should go for it.  At that
point the XML DTD diverges from the SGML DTD.  We know it's
going to happen at some point.  And trying to trick SGML into
behaving like XML for those new features is a misuse of

That doesn't mean the SGML DTD has to be abandoned. New
SGML elements and attributes with normal behavior can be
added in parallel to the XML DTD, just as they are now.
For much of the publishing community that uses DocBook,
that would still be useful.  But XML-enabled features would
be omitted.  Then each user has to decide if they want the
XML-specific features (and the added complexity they most
likely will introduce).  If so, they move to XML.  If not,
they can live with traditional elements and attributes
in SGML.  

In answer to the second question, I think it is premature to
abandon DTDs in favor of a schema. I don't think schemas
are supported well enough in either the tools or the minds
of DocBook users.  I think one or more schemas should be
introduced in parallel to the XML DTD so that we can get
some air time with them.  You already have some experimental
schemas, so perhaps those should move up in status.  

Even if it is hard, I think we should try to implement new
XML features in the DTD, although to tell you the truth,
I'm not clear on how that can be done in some cases.  At
some point, we may find we cannot do some new feature in
the DTD, but we can in a schema.  At that point we decide
to diverge, again.  Then, if you as a user stay with the
DTD, you have this set of features, and if you use the
schema, you have a few more (one would hope not a few less also).

This all sounds kind of theoretical, but the basic principle
I'm trying to get at is an orderly transition to an
enhanced DocBook that doesn't disrupt a well-established
and growing DocBook community.  The process of evolving
the DTD has been an excellent example of anticipating
and preparing users for change.  The new XML features
need to follow the same path.

This path means more work: an SGML DTD, an XML DTD, and one
or more XML schemas.  Is it worth it?  I think so.
Will Norm have to do it all?  For his sake, I hope not.

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
Caldera International, Inc.                 fax:   (831) 429-1887
                                            email: bobs@caldera.com

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

Powered by eList eXpress LLC