problem in redefine xml schema

[junlia]

We are using ACORD xml schema standard, and we need to add to it, so we
choose to redefine ACORD xml schema. One of the problems that I ran into is
how to add some values to an emumerated list.

For an emumerated list like this:
<xsd:complexType name="AttachmentType">
<xsd:simpleContent>
<xsd:restriction base="OpenEnum">
<xsd:enumeration value="040"/>
<xsd:enumeration value="041"/>
<xsd:enumeration value="042"/>
...
<xsd:enumeration value="YDQ"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

I would like to be able to add something like these to the list:
<xsd:enumeration value="abc"/>
<xsd:enumeration value="xyz"/>

But I got when validated with MS parser(.net version): "The complexType
'http://www.ACORD.org/standards/PC_Surety/ACORD1.6.0/xml/:AttachmentType' has
already been declared. An error ed in file: ///c:/myschema.xsd, (48,3)".
However, it was valid with xml spy.

Any thoughts?

[Priscilla Walmsley]

Hello,

You can't extend a simple type to add more enumerated values, even when
using redefine. The best you can do is create a new simple type that is the
union of the ACORD type plus your extra values, for example:

<xs:simpleType name="NewAttachmentType">
<xs:union memberTypes="AttachmentType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="abc"/>
<xs:enumeration value="xyz"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>

Hope that helps,
Priscilla
------------------------------------------------------------------
Priscilla Walmsley
Author, Definitive XML Schema / XML in Office 2003
http://www.datypic.com
------------------------------------------------------------------

"junlia" <ju****@discussions.microsoft.com> wrote in message
news:1A**********************************@microsof t.com...

We are using ACORD xml schema standard, and we need to add to it, so we
choose to redefine ACORD xml schema. One of the problems that I ran into
is
how to add some values to an emumerated list.

For an emumerated list like this:
<xsd:complexType name="AttachmentType">
<xsd:simpleContent>
<xsd:restriction base="OpenEnum">
<xsd:enumeration value="040"/>
<xsd:enumeration value="041"/>
<xsd:enumeration value="042"/>
...
<xsd:enumeration value="YDQ"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

I would like to be able to add something like these to the list:
<xsd:enumeration value="abc"/>
<xsd:enumeration value="xyz"/>

But I got when validated with MS parser(.net version): "The complexType
'http://www.ACORD.org/standards/PC_Surety/ACORD1.6.0/xml/:AttachmentType'
has
already been declared. An error ed in file: ///c:/myschema.xsd, (48,3)".
However, it was valid with xml spy.

Any thoughts?

[junlia]

Thanks for the help, Priscilla,

My problem for creating a new simple type is that we would have to redefine
ton's complextypes, which use the AttachmentType in ACORD. That would open
cans of worms.

I really don't get it why the redefine functionality is so limited, hardly
provide much modularity. We can not extend a simple type ; we can not
restrict a complex type such as restrict <xsd:element ref="ContractNumber"
minOccurs="0"/> to be <xsd:element ref="ContractNumber" minOccurs="1"/> in
the following example:
<xsd:complexType name="Requestor_Type">
<xsd:sequence>
<xsd:group ref="REQUESTORPARTY_CHOICE" minOccurs="0"/>
<xsd:element ref="ContractNumber" minOccurs="0"/>
<xsd:element ref="ProducerSubCode" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="id" type="ID"/>
</xsd:complexType>

Any idea if W3.org would provide more flexibility for redefine an existing
complex schema, such as ACORD standard?

Thanks much for the suggestions,
Junlia
"Priscilla Walmsley" wrote:

Hello,

You can't extend a simple type to add more enumerated values, even when
using redefine. The best you can do is create a new simple type that is the
union of the ACORD type plus your extra values, for example:

<xs:simpleType name="NewAttachmentType">
<xs:union memberTypes="AttachmentType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="abc"/>
<xs:enumeration value="xyz"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>

Hope that helps,
Priscilla
------------------------------------------------------------------
Priscilla Walmsley
Author, Definitive XML Schema / XML in Office 2003
http://www.datypic.com
------------------------------------------------------------------

"junlia" <ju****@discussions.microsoft.com> wrote in message
news:1A**********************************@microsof t.com...

We are using ACORD xml schema standard, and we need to add to it, so we
choose to redefine ACORD xml schema. One of the problems that I ran into
is
how to add some values to an emumerated list.

For an emumerated list like this:
<xsd:complexType name="AttachmentType">
<xsd:simpleContent>
<xsd:restriction base="OpenEnum">
<xsd:enumeration value="040"/>
<xsd:enumeration value="041"/>
<xsd:enumeration value="042"/>
...
<xsd:enumeration value="YDQ"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>

I would like to be able to add something like these to the list:
<xsd:enumeration value="abc"/>
<xsd:enumeration value="xyz"/>

But I got when validated with MS parser(.net version): "The complexType
'http://www.ACORD.org/standards/PC_Surety/ACORD1.6.0/xml/:AttachmentType'
has
already been declared. An error ed in file: ///c:/myschema.xsd, (48,3)".
However, it was valid with xml spy.

Any thoughts?

[Derek Harmon]

"junlia" <ju****@discussions.microsoft.com> wrote in message news:D6**********************************@microsof t.com...

redefine an existing complex schema, such as ACORD standard?
Now, what exactly does that mean? Redefine the *standard*?
It wouldn't be very standard if you redefined it, now would it?

If I write an application that reads your P&C XML, how is it
supposed to know what your custom AttachmentTypes mean?
Isn't specifying a MIMEType enough?

I really don't get it why the redefine functionality is so limited, hardly
provide much modularity.

From my experience with XMLife, which is another ACORD
vocabulary that I believe shares several common design prin-
ciples as far as it's schema goes, considerable discussion and
development went into specifying extensibility points for adding
arbitrary content. There are KeyValues for "enumerated" value
types and OLifeExtension elements marked as type xs:any that
can contain arbitrarily complex, if untyped, content.

Any custom content you place in an OLEx element should,
of course, be scoped within your own namespace URI so it
doesn't conflict with other vendors who've placed extension
information there.
Derek Harmon