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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Schema concepts

[ Lists Home | Date Index | Thread Index ]
  • From: Stefan Haustein <haustein@kimo.cs.uni-dortmund.de>
  • To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
  • Date: Wed, 16 Feb 2000 18:51:16 +0100

"Henry S. Thompson" wrote:
> 
> You can get very close to this now.  I don't consider the difference
> between the above and what follows substantive:  it's a matter of
> making explicit some things which are implicit in the above:
> (...)

Is your example really valid? The specs say "The type 
of every member of an equivalence class must be the 
same as or derived from the type of the exemplar". 
That does not hold for your example. BTW: I should
have added color as attribute of pictureElement in
my example.

Furthermore, your example ignores the following 
requirement:

> > The circle and line elements cannot just have
> > annonymous types since I may want to reuse
> > their structure.

> By separating the 'Address' type definition from the <shipTo> element
> declaration, it becomes possible to add a <billTo> element to my
> PurchaseOrderType definition:
> 
>   <element name="shipTo" type="po:Address"/>
>   <element name="billTo" type="po:Address"/>

That would also be possible with (abstract) elements instead
of types, e.g.: 

   <element name="shipTo" source="po:Address"/>
   <element name="billTo" source="po:Address"/>

> without pretending that they are in some way the same element: they're
> not, they just share a content model and attribute set.  

In OOP the derived class normally is a specialization, 
thus not the same, so where is the problem? 

> Similar to the difference between structure definitions 
> and variable type declarations in a programming language.  

Hm. Are you talking about struct vs. class? 
In modern programming languages you do not neccessarily 
have a difference between classes and structs. I think 
it's more a compatibility thing in C++. 

Furthermore, you could use named groups for structure 
reuse if you insist on having two ways of
structure reuse.

> I claim that declaring elements (identifying their 
> type) separately from defining types (...) is 
> exactly what you want to do, and XML Schema lets 
> you do it.  

Doing everything twice is not what I want to do.
It is ok to me if XML schema lets me do that,
but I do not want to be forced to. Do
you not agree that it should always be a 
design goal for standards to keep them as 
simple as possible (as far as feasible without 
losing the objectives)? I claim that the artificial 
type/element distinction makes xml schema more 
complicated than needed. 

Best regards

Stefan



-- 
Stefan Haustein
University of Dortmund
Computer Science VIII
www-ai.cs.uni-dortmund.de

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************




 

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

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