W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2002

Re: type substitution question

From: Calvin Smith <calvins@sims.berkeley.edu>
Date: Mon, 29 Jul 2002 15:59:30 -0700
Message-ID: <007601c23753$a622d8b0$35c8e80c@c1152589a>
To: <xml-dev-help@lists.xml.org>, <xmlschema-dev@w3.org>, "Danny Vint" <dvint@mindspring.com>

Hi Danny,

This is a very annoying bug in XML Spy.  The element of type OpenEnum should
not have to conform to the data type of any derived types.

A co-worker of mine has submitted a bug report to Altova, and they replied
that it is indeed a bug, and they have submitted it to their dev team.

In the meantime, our 'fix' has been to use Xerces for validation, which is
probably a good thing anyway, since it also catches errors that XML Spy
thinks are okay.

cheers,

calvin

----- Original Message -----
From: "Danny Vint" <dvint@mindspring.com>
To: <xml-dev-help@lists.xml.org>; <xmlschema-dev@w3.org>
Sent: Monday, July 29, 2002 2:39 PM
Subject: type substitution question


>
> I have a schema that defines a standard type (OpenEnum) to be used as the
> basis of all code lists (enumerated lists). In some cases we actually have
> a list of values associated with a specific element and in other cases
> where we don't own the list we just use the base type of OpenEnum as the
> type for the element.
>
> When I validate a stream that has one of these elements of type OpenEnum,
> the tool (XML Spy) comes up with a suggested list of all the code list
> values concatenated together. Is this correct behavior? I thought at least
> I would have to define a substitution group or being using the xsi:type
> attribute to get this flexibility.
>
> Here are the key parts:
>
> ***** Schema definitions
>
> <xsd:complexType name="OpenEnum">
> <xsd:simpleContent>
> <xsd:extension base="OpenEnum_NoID">
> <xsd:attribute ref="id"/>
> <xsd:attribute ref="CodeListRef"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
>
> <xsd:simpleType name="OpenEnum_NoID">
> <xsd:restriction base="NC_NoID">
> <xsd:maxLength value="80"/>
> </xsd:restriction>
> </xsd:simpleType>
>
> <xsd:simpleType name="NC_NoID">
> <xsd:restriction base="xsd:string">
> <xsd:minLength value="1"/>
> <xsd:pattern value="[\p{IsBasicLatin}]*"/>
> </xsd:restriction>
> </xsd:simpleType>
>
> <xsd:element name="CurCd" type="OpenEnum"/>
>
> <xsd:element name="AirBagTypeCd" type="AirBagType"/>
> <xsd:element name="BillingMethodCd" type="BillingMethod"/>
> <xsd:element name="BondTermCd" type="BondTerms"/>
>
>
>
> <xsd:complexType name="AirBagType">
> <xsd:simpleContent>
> <xsd:restriction base="OpenEnum">
> <xsd:enumeration value="Driver"/>
> <xsd:enumeration value="FrontBoth"/>
> <xsd:enumeration value="FrontSide"/>
> <xsd:enumeration value="None"/>
> </xsd:restriction>
> </xsd:simpleContent>
> </xsd:complexType>
>
> <xsd:complexType name="BillingMethod">
> <xsd:simpleContent>
> <xsd:restriction base="OpenEnum">
> <xsd:enumeration value="AB"/>
> <xsd:enumeration value="CAB"/>
> <xsd:enumeration value="CPB"/>
> </xsd:restriction>
> </xsd:simpleContent>
> </xsd:complexType>
> <xsd:complexType name="BondTerms">
> <xsd:simpleContent>
> <xsd:restriction base="OpenEnum">
> <xsd:enumeration value="CON"/>
> <xsd:enumeration value="NRN"/>
> <xsd:enumeration value="REN"/>
> </xsd:restriction>
> </xsd:simpleContent>
> </xsd:complexType>
>
>
> ******** XML Stream
>
>     <CurCd>USD</CurCd>
>
> ************
>
> What XML Spy reports on this element is that "USD" is not allowed, and it
> shows me a list of what is all the other enumerated values without
allowing
> just a plain string that would be from 1 to 80 characters restricted to
the
> basicLatin character set.
>
> Is this a correct behavior?
>
> If it is correct is there anything else that should be in the stream to
> allow me to have just any old value and still keep these similar types of
> elements defined together?
>
> What if I don't want to allow this to happen at all, is there any way I
can
> control this without defining each lists separately?
>
> thanks
> ..dan
> --------------------------------------------------------------------------
-
> Danny Vint
> http://www.dvint.com
>
>
>
>
Received on Monday, 29 July 2002 19:01:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:57 UTC