[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 break? > 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 modularization: "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 disposal. Rob.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]