[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Trouble in Schema Town
Here is the corrected XSD with the changes
listed below:
<xs:element name="powerReactive" type="poo:PowerReactiveType" substitutionGroup="poo:powerItem"/>
<xs:complexType name="PowerReactiveType" mixed="false">
<xs:annotation>
<xs:documentation>Reactive power,
measured in volt-amperes reactive (VAR)</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="false">
<xs:restriction base="poo:PowerItemType">
<xs:sequence>
<xs:element name="itemDescription" type="xs:string"/>
<xs:element name="itemUnits" type="xs:string" fixed="VAR"/>
<xs:element name="scale" type="poo:SiScaleType"/>
<xs:element ref="poo:powerAttributes"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType> Bruce
Bartell Xtensible Solutions From: Considine, Toby (Campus Services IT)
[mailto:Toby.Considine@unc.edu] If you take the last published schemas,
(EMIX only) and work this smaller extract from Power against them, you can see
the problem… And maybe propose the solution. Thanks tc "It is the theory that decides what can
be observed."
- Albert Einstein
From: Bartell, Bruce [mailto:bbartell@xtensible.net] 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]