[
Lists Home |
Date Index |
Thread Index
]
[Danny Vint]
> Questions:
>
> Q1) I have 3 different standards within our organization and they may have
> the same elements and some of the same structures. How should namespaces
be
> used to identify these particular standards? Should I have one Insurance
> domain namespace?
>
I think that, if you have a fairly distinct group of structures or types
with some coherence, that it makes sense to give it a distinct namespace.
This would especially apply to your common (reusable, I presume) elements
and structures. You can import them (into the distinct namespace) into the
other schemas.
At work, we have been working on a schema for Advanced Traveler Information
Systems. It imports about four or five other schemas to get various
capabilities, such as location referencing and event reporting. We gave
each of those pieces their own namespaces, but the top-level schema does not
have its own namespace. So far, we have not come up with a convincing
reason to use a namespace for the top-level elements. If we thought it
might be imported by some other schema, we probably would, but that does not
seem likely right now.
In our case, the other parts are developed by other groups rather
independently, and each having its own namespace makes it really clear that
an independent module is being developed and imported. So far, this plan
seems to be very satisfactory. I admit that we might rethink whether the
top-level schema has its own namespace or not.
Here is an example of (part of ) an instance document:
<origin refID="ID2-1">
<id>F14B011A9D0D</id>
<name>State and Division</name>
<location>
<!-- Contains elements from the "lrms" namespace -->
<lrms:crossStreets>
<lrms:onStreetName>State St.</lrms:onStreetName>
<lrms:fromStreetName>Division St.</lrms:fromStreetName>
<lrms:cityName>Chicago</lrms:cityName>
<lrms:state>IL</lrms:state>
<lrms:country>USA</lrms:country>
</lrms:crossStreets>
<!-- End of "lrms" elements -->
</location>
<pointRole>origin</pointRole>
</origin>
> Our standards are currently divided along the lines of Life, Property,
> Causality and Surety, and Reinsurance, should I have different namespace
> for each? At least one of these specs has been split into 2 parts, one
> being the payload (business/Insurance data) and the other being a
framework
> or messaging structure that includes the payload portion.
>
> Should this be all one namespace or should they be at least 2 namespaces?
> Should the included portion be identifiable by 2 namespaces (one namespace
> being when used standalone and the other when used in the message
structure)?
I would not identify them differently just because they are used in
different contexts. I also do not think that you need two namespaces just
because there are two distinct parts to a message. But if there is a
common, reusable core, there might be a case for its own namespace. On the
other hand, as I said above, that seems to me to make the most sense for
schemas that are really independently developed, especially if it is by
another organization.
>
> Q2) Should a namespace be versioned? This is more for file and element
> identification which fits #1 and #2, but seems contrary to #3.
>
I think we need a best practice for versioning, and although it has been
discussed here there has been no consensus yet. I think namespaces should
not change until the new design instances will seriously break processing
anyway (since changing namespaces is practically certain to break
processing). So there needs to be some other versioning convention.
> Q3) Should a namespace act like a PUBLIC Identifier and be able to
identify
> a specific file and version of a schema (lets ignore DTDs for now)? This
> doesn't mean that I would be able to look up the URL and find the schema,
> but that there should be a unique name/namespace for each version.
>
Not for versions unless they are major changes (see above). For the file,
you do have the SchemaLocation attribute, so you can use that for the
purpose if you like.
Another point to be considering is extensibility. In the ATIS schema, there
is a ***lot*** of desire in the industry to allow local enumerated values
(read: code values). Of course, you can allow any string or number for
enumerations, but then you cannot validate that part of an instance. I have
been experimenting, and what looks really good is to have a separate schema
(with its own namespace) for local user extensions. Only this extensibility
is allowed to be extended (we see no need for restrictions in this work).
Model groups in the extensibility schema work very well, acting much like
parameter entities in DTDs. It is possible to seamlessly extend
enumerations and still validate the instances. Of course, with this
approach you cannot have two independent extensions that have name
collisions.
Model groups also seem to work well for adding new elements into a
structure. You have to restrict these extensions to specific types of
elements, but that is a good practice anyway. If anything anywhere can
change, what good is a schema?
With this approach, and with the right declarations in the top-level schema,
you can extend your enumerations and even element structures without
touching the top-level schema at all, just by adding to the extensibility
types in the extensibility schema. You could mark everything "final" in the
top-level schema and still do the anticipated extensions.
In real applications, it seems that customization can be quite important.
We have not tested this approach that much yet, but it looks very good so
far.
Cheers,
Tom P
|
