Extending schemas

[Danny Vint <dvint@mindspring.com>]

I've got a general design question that I would like input and maybe 
alternate ideas for implementation.

PROBLEM
-----------------
I work for ACORD which is an Insurance industry standards group and we are 
updating our DTD spec to now use Schemas. We have an internal need and 
philosophy to be able to extend our standard to allow for company unique 
information. Our standard covers the common 90% of the need that everyone 
can agree is standard and common requirements. So we need someway to allow 
the additional 10% to be added by specific vendors and carriers.

We don't want wild card or general namespace capabilities that would allow 
any element from any namespace anywhere within our model/design. Instead we 
want a very controlled inclusion or exclusion of elements within content 
models. So that element newA is only allowed in the ACORD D F and G 
elements, but none of the others. We don't want anyone changing the 
datatypes of existing ACORD elements, but we do want them to reuse the 
elements or aggregates (elements composed of elements) as they want or to 
create and use their own elements and aggregates.

The other twist here is that most members are saying they aren't going to 
do validation on their production system. They may test with a schema their 
for validation, but in production they intend to remove this functionality 
and rely on their code to do all the work. We also have everything 
currently defined as global elements, there are no local definitions.

Solutions being considered
----------------------------------------

1) Like Roger Costello'ss Best Practice document, we have had a suggestion 
of using the xsd:any and xsd:anyattributes features, but this allows too 
much flexability. I can use any element from any allowed namespace to be 
used anywhere the 'any' wild card appears.

2) xsd:redefine has also been proposed. I like this idea because it very 
specifically indicates what is being changed and it specifies exactly the 
changes being made. These changes are managed outside of the original 
schema and very explicitly indicates where the modifications have been 
made. The issue raised with this is that some of the members don't want the 
ACORD namespace and elements being trampled on by other 
people/organizations. To me I don't see any problem, the end result is that 
I have an exist ACORD element being extended by adding new company 
elements, existing ACORD elements, or the removal of ACORD elements and all 
of this is managed ultimately with the use of the namespaces and the prefixes.

3) The alternate to #2 is to require the reusing organization to create in 
their own namespace the thing they want to modify. The idea being that they 
would somehow derive their new object from the ACORD element, give it 
essentially the same name in their namespace and then make the 
modifications as they needed. So the parent object and any company unique 
elements are in the companies namespace and ACORD reused elements would 
appear in the ACORD namespace. This new object would then automatically 
replace all the definitions of the ACORD element.

Possible Schema Designs
--------------------------------------

So what we have in the ACORD specification is something like this:

targetNamespace="http:/www.ACORD.opg"
schemaLocation="acord.xsd"

<xsd:element name="FamilyName">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element ref="TitlePrefix" minOccurs="0" maxOccurs="1"/>
             <xsd:element ref="FamilyNames" minOccurs="1" maxOccurs="1"/>
             <xsd:element ref="Surname" minOccurs="1" maxOccurs="1"/>
             <xsd:element ref="NameSuffix" minOccurs="0" maxOccurs="1"/>
          </xsd:sequence>
       </xsd:complexType>

Now company B wants to add a idCode to this element. So with redefine I 
would have something like:

***************

targetNamespace="http:www.A.com"

<xsd:element name="idCode" base="xsd:string"/>


**************

targetNamespace="http:/www.ACORD.opg"

<xsd:redefine schemaLocation="acord.xsd" >

<xsd:element name="FamilyName">
       <xsd:complexType>
          <xsd:sequence>
             <xsd:element ref="A:idCode" minOccurs="0" maxOccurs="1"/>
           </xsd:sequence>
       </xsd:complexType>
</xsd:redefine>

**************

This one I'm less sure of but the indication seems to be:

1) The elements in the ACORD schema would have to be changed to be based 
upon a complexType then that complexType is then used by company A

targetNamespace="http:/www.A.com"

       <xsd:complexType name="FamilyNameType" >
	<xsd:extension base="acord:FamilyNameType"
               <xsd:sequence>
                   <xsd:element ref="idCode" minOccurs="0" maxOccurs="1"/>
               </xsd:sequence>
	<xsd:extension>
       </xsd:complexType>


Now doesn't this all still come down to the following schema instance:

<FamilyName>
             <TitlePrefix/>
             <FamilyNames/>
             <Surname/>
             <NameSuffix/>
             <A:idCode/>
</FamilyName>

Does it really matter which way we use to define the extensions if the 
result is the same XML stream?

Does any of this really matter (or is it even allowed) if we aren't using 
the schema for validation of every stream in production?

Any other ideas or suggestions?

Who is the definitive source on the different ways of doing things? One 
member points to the description in the Schema spec that seems to indicate 
that Redefine was only meant to be used when versioning your own schema and 
not for combining schemas - is this its only allowed use? It seems to me 
that the schema spec has multiple ways/solutions for doing things (for 
instance redefine and any) and it is up to the implementor to decide what 
fits the problem at hand. If that is true then having suggested uses in the 
spec that look like restrictions rather than suggested applications is a 
problem.


..
..dan