OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Content roles in XML

[ 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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS