[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emix] Trouble in Schema Town
It tricked myself that way to. If everything is in the same space (ell in EMIX, all in power) the restriction works just fine. It barks when the abstract class is in Emix, and the restricted concrete class is in Power (or poo), If we want to define it all in Power, then we establish no stereotype for extension of EMIX into other spaces (say NG, or High and Low Pressure Steam), we need to keep EMIX and Power separate. Thanks! tc "He who fights with monsters should look to it that he himself does not become a monster, and if you stare long into an abyss, the abyss also stares into you." - Fredrich Nietzche
From: Bartell, Bruce [mailto:bbartell@xtensible.net] 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> 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. From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com] All -- William Cox 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 PO Item, Requisition Item, Invoice Item, Lading Item. Item does not include Quantity or Price, because a single product description or transaction may have multiple quantities or prices associated with a single item.</xs:documentation> </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 CAM as we go forward. I would welcome a volunteer for that effort. 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]