xml-dev - Re: Schema concepts

[ht@cogsci.ed.ac.uk (Henry S. Thompson)]

[sorry for empty reply a moment ago ;-[

Stefan Haustein <haustein@kimo.cs.uni-dortmund.de> writes:

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

Sorry, I was moving too fast this morning, you're right.
Here's a corrected fragment

<type name="pictureType">
 <element minOccurs="0" maxOccurs="*" ref="pictureElement"/>
</type>

<element name="picture" type="pictureType"/>

<element name="circle" equivClass="pictureElement"/>
 <type source="pictureType" derivedBy="extension">
  ...
  <attribute name="color" type="..."/>
 </type>
</element>


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

I addressed that in the second version, further down.

> > 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"/>

Assuming you meant

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

where po:Address is now an abstract element, no, that's asserts they
are indifferently substitutable for 'Address' wherever it is allowed
in a content model, which is _not_ what you mean.

> > 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? 

This is not OOP.  <shipTo> and <billTo> are not subclasses of an
<Address> element, they are elements which have necessarily identical
content and attributes but are _not_ allowed wherever their parent
would be.

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

No, exactly what I said.  When I define a struct or a class in C++
no-one confuses that with declaring a variable to contain _instances_
of that struct or class.  The parallel isn't exact, but complex types
are similar to structs or classes, and content model particles/local
element declarations are similar to variable declarations in so far as 
the parallel goes through.

> I claim that the artificial type/element distinction makes xml
> schema more complicated than needed.

I'm sorry I haven't explained clearly enough why we think it's not an
articial distinction.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

***************************************************************************
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
***************************************************************************