xml-dev - Re: Schema concepts

[Stefan Haustein <haustein@kimo.cs.uni-dortmund.de>]

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

Example:

<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

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