[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Including multiple schemas - duplicate name errors
- From: Cheryl_Gielau@cargill.com
- To: davec@progress.com, xml-dev@lists.xml.org
- Date: Tue, 21 Aug 2001 14:31:20 -0500
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