[
Lists Home |
Date Index |
Thread Index
]
- From: Richard Light <richard@light.demon.co.uk>
- To: xml-dev@ic.ac.uk
- Date: Thu, 22 Jan 1998 19:23:04 +0000
In message <5040100013910127000002L072*@MHS>, Jim Amsden
<jamsden@us.ibm.com> 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,
>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
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|