Cart
[Home] [By Thread] [By Date] [Recent Entries]
In message <5040100013910127000002L072*@MHS>, Jim Amsden <jamsden@u...> 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@l... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
