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] | [Elist Home]

Subject: Re: DOCBOOK: external entities cannot be valid?

>> / Bob Stayton <bobs@sco.com> was heard to say:
>> | It appears that external parsed entities cannot be
>> | valid XML.  Someone please prove me wrong.
> To which Norm Walsh <ndw@nwalsh.com> 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.


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

Powered by eList eXpress LLC