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: RE: [docbook] Future DocBook Ruminations - Modular Source Files & XInclude

> No offense, but what this crap will be good for? Resulting grammar will 
> be inconsistent and will go against all design rules for markup 
> languages which I know. 

The grammar I suggested is certainly verbose but isn't inconsistent by any
XML standards I'm aware of. Which design rules for markup languages does it

> Splitting document into several files works on 
> physical level, resulting document on logical level should be reasonable 
> structured XML. You can gain this by using external entities and 
> XIncludes, no additional elements needed.

I'm not suggesting changing anything about how external entities or
XIncludes work, or introducing any new mechanisms.

I am suggesting DocBook picks up an explicit dependency on the <xi:include>
element and namespace - not something to be done lightly. For the DocBook
specification the spotlight seems to focus on the processing and XSLT side
of things where obviously XIncludes should never appear, but we should not
forget that this same DTD is important in the editing environment too. From
a document editor's perspective if the official way to do DocBook inclusion
is <xi:include>, then why does any source file containing an <xi:include>
fail to validate against the official DocBook DTD? I know and understand the
current answer to this question, but don't 100% agree with it.

> If some tools have problems with external entities/XIncludes, then fix
> these tools.

To quote Jeff Beal's recent posting about current editor support for

  "Epic wraps the DOCTYPE declarations with XML comments.
  Emacs/PSGML uses local buffer variables to point to the
  parent document. XMetal uses a processing instruction to
  point to the DTD.  WordPerfect has a catalog that maps
  the root element to the DTD."

Is this what you mean by "fix"? It's a subjective point, by I think even my
admittedly inelegant solution less of a hack than any of the above.

> But don't touch XML sources, they should be there for many 
> years, they are important.

Yes they are important, but sources have to be edited as well as processed,
and in the real world editing rapidly implies errors. The earlier you find
the errors, the faster your documents go out the door. The best way to find
errors is to validate against a grammar.

I'm just looking for a standards-compliant and practical way to allow
validation of document fragments without relying on hacks in particular
editing environments and without compromising the rigor of the DocBook
grammar. It seems odd that this requirement should prove such a difficult
one to solve given all the powerful XML technologies and standards at our


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