[
Lists Home |
Date Index |
Thread Index
]
- From: David Beech <dbeech@us.oracle.com>
- To: "Roger L. Costello" <costello@mitre.org>
- Date: Thu, 15 Jun 2000 14:33:01 -0700
"Roger L. Costello" wrote:
>
> Hi Folks,
>
> I have three related questions (below). Any thoughts that you might
> have on any of these questions would be appreciated. /Roger
>
> -------------------------------------------------------------------
> Question 1.
>
> Suppose that I have a collection of XML Schemas and the schemas are
> related.
>
> Example (auto industry). Suppose that I have an XML Schema for each
> type of auto:
>
> truck.xsd - schema for trucks
> suv.xsd - schema for sports utility vehicles
> minivan.xsd - schema for minivans
> sedan.xsd - schema for sedans
> coupe.xsd - schema for coupes
> etc.
>
> What namespace do I use for the schemas:
>
> (1) A single, umbrella, namespace for the entire collection? Thus, each
> of the above auto schemas would have the same targetNamespace.
>
> or,
>
> (2) A different namespace for each schema? Thus, each of the above auto
> schemas would have a different targetNamespace.
>
As Henry said, one would need to get down to more detail on factors
affecting a decision. But I'll outline an approach that I would
usually feel comfortable with personally. This is to follow a
conventional programming language style of treating the schemas and
their namespaces as primarily defining types in packages or modules.
Complex types can use local names for their element children (and for
their attributes) which appear "unqualified" in the instance, i.e.
unprefixed and (for elements) not within the scope of any default
namespace declaration.
Then an instance might look like
<auto:inventory xmlns:auto='autoURI'>
<vehicle>
<truck>...</truck>
<quantity>37</quantity>
</vehicle>
<vehicle>
<truck>...</truck>
<quantity>21</quantity>
</vehicle>
<vehicle>
<suv>...</suv>
<quantity>15</quantity>
</vehicle>
...
</auto:inventory>
In this way, the namespace decisions and complexities can be kept
within the schemas and the way they refer to each other's
components, rather than intruding into the instance. The autoURI
namespace defines the top-level element named "inventory" (and
probably others), and once that is correctly identified as the root
element of the instance, everything can flow through the types.
This is using the declarative power of schemas to the full - the
knowledge about types and namespaces is not being distributed
throughout the instance, but can be discovered from the schema
(or PSV-infoset) when desired - just like interpreting names in
programming language or database language expressions by reference
to their declarations or schema definitions.
This is one end of the spectrum provided by XML Schema, but you are
of course free to choose other points on the spectrum, ranging to the
other extreme where every element is explicitly qualified by a
namespace, and every element name corresponds one-to-one to a type name,
so that you have distributed much of the schema information throughout
the document instance.
> -------------------------------------------------------------------
> Question 2.
>
> If I were to use the single, umbrella, namespace then when I create,
> say, coupe.xsd would I need to examine all the other schemas to ensure
> that I don't declare an element with the same name? Stated another way,
> is the scope of an element declaration confined to the schema document,
> or, to the namespace (which in my example spans multiple schema
> documents)?
If you are using top-level ("global") element declarations, their
names must be unique among such element names per namespace.
But using the approach above, coupe.xsd might only contain
type definitions such as
<complexType name='coupeType'>
<element name='model' type='xsd:string'>
...
</complexType>
and then it's only the type names that need to be unique per
namespace. Elements like 'model' declared using the name='...' form
within a type definition have local names, which need only be
unique among elements local to that type definition. (It is
permissible for such an element declaration for a local name to appear
more than once within a content model, provided that its associated type
is the same.)
> -------------------------------------------------------------------
> Question 3.
>
> Consider a respository of namespaces (and the elements associated with
> the namespaces). For managing things it might be easier to have one
> namespace for the collection than separate namespaces. Any thoughts on
> this?
I'm all for keeping namespace management as simple as possible, and
would expect to often use local naming as a way of subdividing
namespaces into multiple "symbol spaces", for elements as for
attributes,
rather than introducing additional namespaces.
But this is very much a matter of taste! XML Schema gives you the
options.
David
***************************************************************************
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/
***************************************************************************
|