[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Define a root in a DTD
- From: Peter Flynn <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 26 Jun 2001 20:16:16 +0100
On Tue, 26 Jun 2001, you wrote:
> Hi Peter,
> I think you should not genalize it so.. This generalization might be true
> often, but need not always be.
That is in the nature of generalisations. It is usually more
important to use the frequently-occurring case as an example
when explaining something, than to cloud the issue with
borderline cases and special parameters. They can come later.
There are indeed some poorly-written DTDs which show ambiguity;
some poorly documented DTDs which do not make it obvious; and
some explicitly-designed DTDs which use a feature like
recursiveness (as John showed). Any element type can be the root
element, but we are dealing here with those which are *intended*
to be the possible root element.
But I would assert (purely from personal experience: I offer
no formal proof) that the majority of DTDs betray one or more
possible intended root elements by virtue of the fact that they
are not included in any content model or are so placed in the
hierarchy that the intent is obvious (for example a
documentation DTD might offer MANUAL and CHAPTER as obvious
potential root element types, even though the latter is in the
content model of the former).