>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,
>eventMethod+)>
><!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;,
>%eventMethod;+)>
><!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@light.demon.co.uk