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

Re: Schema concepts

• From: ht@c... (Henry S. Thompson)
• To: haustein@k...
• Date: 16 Feb 2000 18:13:54 +0000

[sorry for empty reply a moment ago ;-[

Stefan Haustein <haustein@k...> 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@c...
		     URL: http://www.ltg.ed.ac.uk/~ht/

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

• Follow-Ups:
  • RE: Schema concepts
    • From: "Jeff Lowery" <jlowery@s...>
  • Re: Schema concepts
    • From: Stefan Haustein <haustein@k...>

• References:
  • RE: Schema concepts (was Re: W3C public lists (was Re: The Power of Groves))
    • From: Michael Rys <mrys@m...>
  • Re: Schema concepts (was Re: W3C public lists)
    • From: Stefan Haustein <stefan.haustein@t...>
  • Re: Schema concepts
    • From: Stefan Haustein <haustein@k...>
  • Re: Schema concepts
    • From: ht@c... (Henry S. Thompson)
  • Re: Schema concepts
    • From: Stefan Haustein <haustein@k...>

• Prev by Date: Re: Schema concepts
• Next by Date: A pecorial error
• Previous by thread: Re: Schema concepts
• Next by thread: Re: Schema concepts
• Index(es):
  • Date
  • Thread