This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: [docbook] Re: Ruminations on the future of DocBook
- From: Tobias Reif <tobiasreif at pinkjuice dot com>
- To: docbook at lists dot oasis-open dot org
- Cc: Norman Walsh <ndw at nwalsh dot com>
- Date: Thu, 31 Jul 2003 11:55:36 +0200
- Subject: Re: [docbook] Re: Ruminations on the future of DocBook
- References: <878yspd1hn.fsf@nwalsh.com> <3ED72340.7040906@pinkjuice.com> <87he5lro5p.fsf@nwalsh.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/
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org