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: XML-Dev Mailing list <xml-dev@xml.org>
  • Date: Wed, 16 Feb 2000 20:40:23 +0100

"Henry S. Thompson" wrote:
> [sorry for empty reply a moment ago ;-[

I thought you were already running out of arguments :-)

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

But with the changes and the reuse option, 
your example seems more or less identical to
my initial one....?

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

I assumed equivClass and source would be merged when the 
element/type distinction is removed.

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

Yes, that's exactly what I mean. Please note that 
your po:Address cannot be used anywhere 
in a content model directly since it is a type. 

You can avoid global visibility of derived elements 
by declaring them locally. Also, nothing hinders you 
from deriving from Address wherever you want to avoid
that other elements derived from Address are inserted.


<element name="address" source="po:Address">

Since address is a subclass of po:Address, you cannot
substitute it by shipTo/billTo. 

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

Can you explain the meaning of "equivClass" in
this context?

OK, I agree that I need variables, types, and
instances in an OOPL.

But would you say that the following is impossible:

1. rename all types in an XML 
   schema that conflict with 
   element names,

2. merge the type and element
   functionality, and

3. the schema would still be operational? (and could
   probably become much shorter by removing some
   then unneded intermediate former types)

Best regards


Stefan Haustein
University of Dortmund
Computer Science VIII

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