[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Andrew Layman <andrewl@m...>
  • To: 'Rick Jelliffe' <ricko@a...>, Jonathan Robie <jwrobie@m...>
  • Date: Tue, 30 Sep 1997 14:37:14 -0700

dog attributes
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@m...

> -----Original Message-----
> From:	Rick Jelliffe [SMTP:ricko@a...]
> Sent:	Monday, September 29, 1997 9:51 PM
> To:	Jonathan Robie
> Cc:	xml-dev@i...
> 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@m...>
> > To: ricko@a...
>  
> > 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@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...)

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.