xml-dev - RE: revised Animal-friends implemented as a pattern (Re: XML-Data:advant

[Andrew Layman <andrewl@microsoft.com>]

I have been staying out of this discussion, despite its interest to me,
in order to concentrate on the vital issue of namespaces.  However, I
assure you that there was no attempt in XML-Data to make "any" differ
from its current use in DTDs.  If it has flaws in that area, I am
interested in fixing them.

--Andrew Layman
   AndrewL@microsoft.com

> -----Original Message-----
> From:	Rick Jelliffe [SMTP:ricko@allette.com.au]
> Sent:	Monday, September 29, 1997 9:51 PM
> To:	Jonathan Robie
> Cc:	xml-dev@ic.ac.uk
> Subject:	Re: revised Animal-friends implemented as a pattern (Re:
> XML-Data:advantages over DTD syntax?)
> 
> Someone has pointed out that the colonized syntax would be
> approporiate and clearer.  Here it is again (sorry!) with
> colons.  (I have also cleaned up the inheritance to bundle
> things more, so please delete previous version.)
> 
> Actually, this following fragment is illegal, because 
> you cannot use ANY inside a content model. I am not sure how
> to read the XML-data format here, but I think this exposes
> a flaw in their example:  if pet can contain any subelements,
> what use is it to say it can also contain a kitten subelement?
> Duplicate paths are a little worrying, if that what they
> have done.
> 
> If it were desired to use ANY in this way (i.e. different
> to how SGML uses it), then it could be coped with by
> parametising includes and excludes in a similar fashion.
> (Again I can provide example if needed, but I hope not.)
> 
> ----------
> > From: Jonathan Robie <jwrobie@mindspring.com>
> > To: ricko@allette.com.au
>  
> > At 05:02 AM 9/30/97 +1000, Rick Jelliffe wrote:
> >  
> > >If you want multiple inhereitance, then you can just 
> > >define a different suffix, and search through attributes
> > >based on that to collect the inheritance tree. I can
> > >provide an example if anyone is interested.
> >  
> > Please!
>  
> Here is a version which allows multiple inheritance.
> (Some parenthesis problems fixed too.)
> I have put in even empty attribute values, to make
> the pattern uniform in every case, so please do not
> confuse this simplicity for elaborateness!
> 
> To extract the inheritance tree, collect all attributes
> with ":inherit" suffix.  I think the only novel thing
> is that people are not used to wildcard searches on 
> attribute names, but this is only prejudice.
> 
> Also, I think because some tools require precompiled
> DTDs, there is a general view in some circles that
> DTDs are always compiled, and always made prior
> to the generation of the instance. But that is
> not intrinsic to SGML.
> 
> The PATTERN
> -----------
> 
> This pattern reserves the suffixes:
> 	contents	 for a parameter entity with the 
>                        element type's contents
> 	attributes  for a parameter entity with the 
>                        element type's attributes
> 	inherit     for a fixed attribute with the 
>                        element type's immediate inheritance
> 
> The pattern is
> 	<!ENTITY % {GI}:contents
> 		" {CONTENT-MODEL}
> 		{INHERITED-CONTENT-MODELS} ">
> 	<!ENTITY % {GI}:attribute
> 		" {ATTRIBUTE-DECLARATIONS} 
> 		{INHERITED-ATTRIBUTE-DECLARATIONS}
> 		{GI}:inherit CDATA #FIXED '' ">
> 	<!ELEMENT {GI}
> 		( %{GI}:contents; ) >
> 	<!ATTLIST {GI}
> 		%{GI}:attributes;
> 		>
> Where the delimiters {} indicate parameters of the template
> which you or your application edit in.  
> 
> The EXAMPLE
> -----------
> 
> <!DOCTYPE animal-friends
> [
> <!-- Handle animal friends ================================= -->
> <!ENTITY % animal-friends:contents 
> 	" ( pet | cat | dog )* "
> <!ENTITY % animal-friends:attributes
> 	"  animal-friends:inherit CDATA #FIXED '' ">
> <!ELEMENT  animal-friends
> 	( %animal-friends:contents; )>
> <!ATTLIST animal-friends
> 	%animal-friends:attributes;
> 	>
> 
> <!-- Handle pets =========================================== -->
> <!ENTITY % pet::contents 
> 	" ANY " >
> <!ENTITY % pet:attributes 
> 	" name ID #IMPLIED
> 	owner ID #IMPLIED 
> 	pet:inherit CDATA #FIXED '' "
> 	 >   
> <!ELEMENT pet
> 	%pet:contents;  >
> <!ATTLIST pet
> 	%pet:attributes;
> 	>
> 
> <!-- Handle cats =========================================== -->
> <!ENTITY % cat:contents
> 	" ( %pet:contents;, kittens)? " 
> <!ENTITY % cat:attributes
> 	" lives NMTOKEN #IMPLIED 
> 	%pet:attributes;
> 	cat:inherit CDATA #FIXED 'pet' ">
> <!ELEMENT cat
> 	( %cat:contents; )
>  <!ATTLIST cat
> 	%cat:attributes;
> 	>
> 
> <!-- Handle dogs =========================================== -->
> <!ENTITY % dog:contents
> 	" ( %pet:contents;, puppies?) " 
> <!ENTITY % dog:attributes
> 	" breed CDATA #IMPLIED
> 	 %pet:attributes;
>        dog:inherit CDATA #FIXED 'pet' ">
> <!ELEMENT dog
> 	( %dog:contents; )
>  <!ATTLIST dog
> 	%dog:attributes;
> 	>
> ]>
> 
> <animalFriends>
>   <cat name="Fluffy" lives='9'/>
>   <pet name="Diego"/>
>   <dog name="Gromit" owner='Wallace' breed='mutt'/>
> </animalFriends>
> 
> 
> Please note that I am not saying that this form is always
> preferable to using AFs or XML-data.  But it can be done
> in XML as it stands now, keeping valid SGML declarations.
> And, as has been mentioned, there should be interconversion
> possible between the three forms, since they give the
> same information.  If XML-data requires the use of specialist
> tools to mapulate, since it is so verbose, then this pattern
> cannot either be regarded as excessively verbose either, 
> since the same kind of tools can be constructed to simplify
> creating new objects.
> 
> 
> Rick Jelliffe
> 
>  
> 
> 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)

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)