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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Including multiple schemas - duplicate name errors



So how far do you take that concept?

Agree that it's a very viable option, 
for the immediate problem that I'm 
faced with.  However, let's say there 
are other schema's that will be 
developed in the future that will 
use this same 'vocabulary' but instead 
of using the elements in schema D, I only 
need a subset of them plus a couple
others for a new schema.  Would need
to break the subset of common elements
down more.

You could take it to the point where 
every element is in it's own schema.  
The resulting messages are just 
comprised of of the appropriate
included single element schemas so 
that this issue wouldn't rear its
head again as schemas are embedded
in other schemas or re-packaged.
 
Sure it's overkill, but if you plan 
to extend the message set, it's 
possible to run into this situation
again and again.

Thanks for your input!
Cheryl

-----Original Message-----
From: davec@progress.com [mailto:davec@progress.com]
Sent: Tuesday, August 21, 2001 2:08 PM
To: Gielau, Cheryl /mtka; xml-dev@lists.xml.org
Subject: RE: Including multiple schemas - duplicate name errors


> I am using seperate schemas since one (A)
> represents a particular kind of operational
> event (the weight of product)and the other (B)
> represents a different kind of operational
> event (the quality of product).
> At points in the workflow, the messages are
> sent seperately.  However, they do have
> some element names that are in common
> like TransportationMode, ServiceLocation
> and others but that are defined globally
> in each of the A and B schemas.
>
> Later in the workflow Schema C packages schemas
> A and B together, along with some additional
> instructions.  In schema C, since A and B are
> included, I get the error that TransportationMode
> and ServiceLocation & others have been defined
> more than once.
>
> Cheryl

You should package up all common definitions in a schema D. Include 
schema D
in A and B. When C includes A and B, you will not get your duplicate
definition error, because there is only a single source (schema D) for 
those
definitions.

Dave