Re: [docbook] Re: Ruminations on the future of DocBook

[Tobias Reif <tobiasreif@pinkjuice.com>]

Norman Walsh wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> / Tobias Reif <tobiasreif@pinkjuice.com> was heard to say:
> | * will depend less on any specific schema language such as DTD (no
> | schema supplied attribute values etc).
> 
> I'm certainly in favor of removing dependencies such as defaulted
> attribute values.


Great! That will save people some trouble and headache.

IMHO, there should be no such dependencies in future versions of 
DocBook, no matter what schema language the feature comes from.

> But I do think we need to have a normative, formal
> schema to define what "valid" means for DocBook documents.


Yes.


> | * will not contain any presentational features.
> 
> That's a laudable goal,


Do you share it?

> but my experience suggests that the
> distinction between semantic and presentational is not black and
> white.


But in many cases it is. Stuff like table frame="" is nothing but 
visual, presentational styling code which does not belong into a 
semantic, structural, and media-independent document language such as 
DocBook, especially not into a "refactored" next generation DBX. Styling 
borders is the domain of languages such as XSLFO, CSS, etc.

Sure, styling code often implies some semantics (but that's most often 
insufficient and ambiguous, that's why we have explicit sematic markup), 
and sure there's stuff which lies between presentation/styling and 
semantics/structure, but in many cases it's very clear what's styling 
and what's not.

To illustrate my point of being media-independent and purely about 
semantics and structure:
If you want to continue to include styling features in DocBook (I hope 
you don't :), then why not include aural styling code as well?


> | * will be as media-independent as possible.
> 
> That seems like a good goal.


Sounds great!


> | "We'd use RELAX-NG."
> |
> | This seems to be a very fine schema language, but there are others. I
> | hope that DocBook won't again depend on one specific schema language.
> 
> That depends what you mean by "depends", I guess. I don't think it's
> practical to say that the only normative definition of DocBook will be
> natural language prose.


I didn't mean that there should be no normative schema, but instead I 
meant that it should be impossible for DocBook documents to require the 
implementation (parser, transformer) to support a certain schema 
language (which is the case with DTDs) or to read a schema first. To 
satisfy this (well, the former issue) it will probably suffice to remove 
default attributes etc from the DTD, but I wanted to re-iterate that 
such dependencies (as with DTD's default attributes) should not be 
re-introduced. I know that one of the design goals of Relax NG is to not 
change the information set of the document, so there currently is no 
threat coming from that particular schema language. But other other (or 
future) schema languages might have features which make documents depend 
on it, and those should be avoided.

Unfortunately DTD is still part of XML and parser are required to read 
the internal subset, so people can always throw lots of DTD stuff into 
their documents.
So on the one hand you can (and should) remove dependencies such as 
defaulted attribute values (as you said above), but on the other hand we 
can't keep people from making their documents depend on schema code, and 
from requiring their tools to support one specifuic schema language (eg 
DTD).


> | "We'd design for the web."
> |
> | I suggest to forget the web when designing DocBook, as much as possible.
> | If DocBook stops being media-independent, I will stop using it. If I
> | author for one single specific medium, eg the web, I use a
> | media-specific language, eg XHTML. If I need media-independence, I can
> | use DocBook.
> 
> I didn't mean the web to the exclusion of other media.


What does "design for the web" mean? If DocBook is to be 
media-independent (our shared goal, see above), then no specific medium 
can be included or excluded.
I suggest to not think about specific any specific medium when designing 
the next generation DocBook, as far as possible. We don't know what new 
media will be introduced in the next ten years.


> | "We'd almost certinaly put it in a namespace."
> |
> | That's good. XSLT, SVG, all are in their namespace, and it's no problem.
> 
> It's a problem if you still want to use DTDs and it's a nearly
> insoluble problem if you want to mix namespaces and use DTDs
> simultaneously.


Yes, DTDs plus namespaces can cause some trouble. But I think it's still 
worth it to put DBX in a namespace, since namespaces are part of the 
present and future.
(BTW, people even do the insoluble [1])

A document can then specify which markup language it's written in, 
without including schema language specific code (such as a DTD doctype 
declaration). If we have a namespace plus a version and optional profile 
attribute (se SVG mobile profiles etc), applications processing the 
document (valiodator, XSLT, etc) can know what type of document they're 
dealing with, and act accordingly (eg fetch the appropriate local 
RNG/DTD/WXS for validation).


> | One specific point: XLink might be a candidate for the linking
> | mechanism; SVG uses it for example.
> 
> It might be. There's still (alas) plenty of controversy about XLink.


Yes, but sometimes it's a good fit; XLink works OK in SVG.

Tobi

[1]
http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/

-- 
http://www.pinkjuice.com/