ANNOUNCE: Virtual Hyperglossary (VHG) DTD 1.0 alpha

[Peter Murray-Rust]

At 11:36 04/06/98 -0600, Joel Riedesel wrote:
>
>Preface:
>  I'm using this vhg.dtd to test out some work we're doing with parsing out
>  the DTD and using that to allow authors to reference data in documents
>that
>  use that DTD (and subsequently be able to reason upon that data).

Thanks very much for taking the time to test it :-).

>
>DTD Parsing Assumption:
>  I had made an assumption (probably quite incorrectly) that there would
>only be
>  element in the DTD that wasn't referenced by other elements and therefore
>I
>  would use that element as my "top" element.

This is a natural and (I believe) false assumption.  A DTD need not have a
hierarchical structure, though most do. The following is acceptable:
<!ELEMENT A (#PCDATA)>
<!ELEMENT B (#PCDATA)>
<!ELEMENT C (#PCDATA)>

It is then possible to have any of the following:
<!DOCTYPE A> <A>I am an A</A>
<!DOCTYPE B> <B>I am an B</B>
<!DOCTYPE C> <C>I am an C</C>

It is one of the 5 myths (I think Eliot Kimber said this) that DOCTYPE
tells you what the document type is. It simply gives the root element and
the set of ELEMENTs that can be used.


>
>Question:
>  This vhg.dtd has a locatorLink that is not referenced by any other
>  element in the DTD.  The semantics of extendedLink say that it will
>  always contain locatorLink elements, but the DTD for extendedLink doesn't
>  actually state that.

This is a shortcoming of the DTD approach to constraining content.
Originally XLink was constructed as
<!ELEMENT extendedLink (locatorLink)*>

Then it was thought it would be useful to have text amongst the links, e.g:
<extendedLink role="family">
<P>once upon a time there were three bears 
<locatorLink role="father" href="bears.xml#id(papa)"/>
<locatorLink role="mother" href="bears.xml#id(mama)"/>
<locatorLink role="child" href="bears.xml#id(baby)"/>
</extendedLink>

There is no way in XML of saying you must have certain content and you may
have some other undefined in the DTD. A content model of
(locatorLink*, ANY) would do the trick, but it's not allowed. There is
discussion as to how to extend this so it can be expressed. I am sure some
people more informed than me will comment on current initiatives in SGML
and XML.

>
>So... somewhat obviously, I end up with the locatorLink as my top element.
>Oops.  (Looks like I need to at least provide for the possibility of
>multiple
>top elements and let our author choose the correct one.)

The DTD cannot require you to have a hierarchy. It can only tell you
whether the hierarchy you have chosen is compatible with the DTD.


>Is this type of DTD practice in any way standard?  It sure feels a bit
>messy to define things this way (makes it tough to use the DTD by another

That is why a number of people are actively discussing schemas. It is a
possible way to extend the semantic expressibility.

>program and actually automate XML things...).  If the authors of the VHG.dtd
>find the need to define things this way, is that due to a current limitation
>of DTDs in general?

Yes :-)

>
>Feel free to correct any misunderstanding I may have (which I won't
>be at all surprised about).

Delighted. That is one reason we are here... Lots of people did it for me
when I was learning (and I still am :-)


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)