[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Trouble in Schema Town
Toby, can you send the versions that are
causing the problem? I thought changing the elementFormDefault
to “unqualified” for both schemas might help, but with the imports
that might make things worse. Bruce
Bartell Xtensible Solutions From: All --
I am having an issue with cross-schema restrictions. I can
work around it, but if anyone can suggest a solution, that would be nice. In EMIX.XSD we have
<xs:element name="itemBase" type="emix:ItemBaseType" abstract="true"/>
<xs:complexType name="ItemBaseType" abstract="true" mixed="false">
<xs:annotation>
<xs:documentation>Abstract
base class for units for EMIX Product delivery, measurement, and warrants. Item
as in
</xs:annotation>
<xs:sequence>
<xs:element name="itemDescription" type="xs:string"/>
<xs:element name="itemUnits" type="xs:string"/>
<xs:element name="scale" type="emix:SiScaleType"/>
</xs:sequence>
</xs:complexType> In Power.XSd, we extend this (showing Power only)
<!-- ==================================================== -->
<!-- 9.9.5 Base Power Item Type -->
<!-- ==================================================== -->
<xs:element name="powerItem" type="power:PowerItemType"/>
<xs:complexType name="PowerItemType" abstract="true" mixed="false">
<xs:annotation>
<xs:documentation>Denominations
for the measurement of Power</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:extension base="emix:ItemBaseType">
<xs:sequence>
<xs:element ref="power:powerAttributes"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- ==================================================== -->
<xs:element name="powerAttributes" type="power:PowerAttributesType"/>
<xs:complexType name="PowerAttributesType">
<xs:sequence>
<xs:element name="hertz" type="xs:decimal"/>
<xs:element name="voltage" type="xs:decimal"/>
<xs:element name="ac" type="xs:boolean"/>
</xs:sequence>
</xs:complexType> And then restrict them as follows
<!-- ==================================================== -->
<xs:element name="powerReal" type="power:PowerRealType"
substitutionGroup="power:powerItem"/>
<xs:complexType name="PowerRealType" mixed="false">
<xs:annotation>
<xs:documentation>Real
power measured in Watts (W) or Joules/second (J/s)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:restriction
base="power:PowerItemType">
<xs:sequence>
<xs:element name="itemDescription" type="xs:string" fixed="RealPower"/>
<xs:element name="itemUnits">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="W"/>
<xs:enumeration value="J/s"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="scale" type="emix:SiScaleType"/>
<xs:element ref="power:powerAttributes"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType> This should produce correct results. It
validates in many tools, but not in XMLSpy. In XML Spy, this is invalid as it
sees: Type 'power:PowerRealType' is not a valid restriction
of type 'power:PowerItemType'. (see Details)
Error location: xs:schema / xs:complexType / xs:complexContent / xs:restriction
/ @base
Details
rcase-NameAndTypeOK.1: The declarations' {name}s and {target namespace}s are
not the same: restriction element is <xs:element
name="itemDescription"> and base element is <xs:element
name="itemDescription">.
rcase-Recurse.2.2: Mandatory <xs:element name="itemDescription">
is missing in the <sequence>. Several other tools validate it as OK. It seems to be
an edge case that was much discussed during the development of the current
draft of XSD. I am not even certain that it is invalid. Still, if XMLspy is the
tool folks will use to validate, this is a problem. For now, I can work around it by making Item a null
abstract class, and doing all the typing inside Power. This will give correct
XML that validates in XMLSpy, and I can fix it to be what I would prefer when
someone suggests a work-around. Some of the examples shared on this list recently have
been very informative. We have to shy away from non-recommended standards such
as SAWSDL which are not fully conformant with WSDL 2. Perhaps we can accomplish
the same type of semantic typing with tc “The single biggest problem in communication is
the illusion that it has taken place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]