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]

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


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


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