[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: external entities cannot be valid?
>> / Bob Stayton <email@example.com> was heard to say: >> | It appears that external parsed entities cannot be >> | valid XML. Someone please prove me wrong. > > To which Norm Walsh <firstname.lastname@example.org> replied: > Uh, I'm not sure what you mean. > A document that uses external > parsed entities can certainly be valid. Yes, the document using the entity can be valid, but I was referring to the external parsed entity itself, the included XML file. > | Option A: Leave out the doctype declaration from the > [...] > | > | Option B: Include the doctype declaration in each chapter > [...] > > You couldn't do this with SGML, either, so I'm a little > confused. It's cold comfort that you couldn't do valid modular files in SGML either. I thought XML was the *improved* version of SGML. 8^) Quoting the XML 1.0 spec (section 4.4.3): "... the automatic inclusion provided by the SGML and XML entity mechanism, primarily designed to support modularity in authoring, ..." So the mechanism partially supports modularity if you create the rest of the solution yourself. > | Option C: Leave out the doctype declaration in each chapter > [...] > > Well, even worse than that is the fact that you can't do this: > > <!DOCTYPE chapter PUBLIC "..." "..." [ > <!ENTITY chapter SYSTEM "..."> > ]> > &chapter; > > Option C is very troublesome to implement. Ack, you are right, making a chapter wrapper file an entity reference to the whole content does not work, but I don't see why. I presume this is because the root element of a valid document must be in the document before the external entities are processed. But I looked through the spec but could not find where this type of usage is not allowed. > Personally, I use option A and do validity checking against the > whole book (er, except when I'm using Adept/Epic which allows you > to have your cake and eat it too in this regard :-), but in your > environment, it sounds like B is probably slightly easier for > your authors, you just need to automate the book-building process > with Makefiles or a script or something. So you use option A, but recommend B, and Terry uses C. I guess that confirms that I need to come up with my own solution. Just wanted to make sure I wasn't developing something I didn't need to develop. BTW, I took a look at xinclude, and its current discussion of validation of merged content is a bit troublesome. Statements like make me wonder a bit: "NOTE: The DTD or Schema used for validation may need to be adjusted when running a particular document through an XML processor instead of a XInclude processor. A validating XInclude document is not necessarily a validating XML document, and vice versa." I'll have to study it some more to see if it will solve the problem in the long run. bobs
Powered by eList eXpress LLC