Content roles in XML

Richard Light richard at
Thu Jan 22 19:27:42 GMT 1998

In message <5040100013910127000002L072*@MHS>, Jim Amsden
<jamsden at> writes

>The content of an Event set includes two required methods, and a collection of
>other methods. In the DTD, there's no way that I know of to indicate the roles
>these methods play in the EventSet. I would like to say something like:
><!ELEMENT EventSet (Annotation*, addListenerMethod, removeListenerMethod,
><!ATTLIST EventSet
>  %FeatureDescriptor;
>  listenerType CDATA #REQUIRED
>  isInDefaultEventSet (true | false) "false"
>  isUnicast (true | false) "false"
>where addListenerMethod, removeListenerMethod, and eventMethod are all Method
>elements. This more clearly describes the content of an EventSet and avoids
>using positioning only to capture the meaning of element content. I could use
>parameter entities to achieve this effect as in:
><!ENTITY % addListenerMethod "Method">
><!ENTITY % removeListenerMethod "Method">
><!ENTITY % eventMethod "Method">
><!ELEMENT EventSet (Annotation*, %addListenerMethod;, %removeListenerMethod;,
><!ATTLIST EventSet
>  %FeatureDescriptor;
>  listenerType CDATA #REQUIRED
>  isInDefaultEventSet (true | false) "false"
>  isUnicast (true | false) "false"

>Is this reasonable? Good XML DTD style? Not too much of a runtime overhead? A
>common practice? Note that this probably wouldn't help with the parsed XML as
>there would be a Method element for each method. You couldn't ask an EntitySet
>element for it's addListenerMethod content like you could ask it for it's
>isUnicast attribute. You'd have to know to get the first Method in the content.
>Of course an extensible parser with factory methods for constructing parse tree
>nodes could hide the position dependence and provide more meaningful accessors.

Can't you just declare an attribute list for Method which includes a
MethodRole attribute?  That way, the information is still available in
the parsed document.  Using parameter entities in the way you suggest is
really not a good idea for the reasons you outline - your intent is
clear to a human reader looking at your DTD, but the subtle distinction
is long gone by the time software gets to look at your instances!

Richard Light.

Richard Light
SGML/XML and Museum Information Consultancy
richard at

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

More information about the Xml-dev mailing list