With absolutely NO knowledge whatsoever, I will take a poke in the dark. Since in Java, URI is not a subclass of String, it make sense that anyURI in XSD should not be a subclass of String. More abstractly, I could see the argument that anyURI by nearly coincidence is a string representation of a URI but really is its own structured type (protocol + host + file part + query ... ) similar as one might say a Point object could have a String representation "X,Y" but that doesn't make it a subclass of String, or even integer could be but isn't a subclass of string. -David From: Michael Kay [mailto:mike@saxonica.com] If you're only using a schema for validation, then the type hierarchy makes very little difference (except perhaps for some maintainability benefits if you get it right - but even then, not much). I have a question of Style and Substance in XSD I have a number of top-level elements that are variants of one another. Each of these appears in multiple Types (worthy of top-lelvelness). Let’s say we have uid as a simple base type. <xs:element name="uid" type="UidType"/> <xs:simpleType name="UidType"> <xs:annotation> <xs:documentation>Unique Identifier</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> A) One approach has me fully typing each derived element <xs:element name="fooID" type="FooType"/> <xs:simpleType name="FooType"> <xs:annotation> <xs:documentation>Identification of foo. </xs:documentation> </xs:annotation> <xs:restriction base="UidType"/> </xs:simpleType> <xs:element name="feeID" type="FeeIDType"/> <xs:simpleType name="FeeIDType"> <xs:annotation> <xs:documentation>Identification of fee </xs:documentation> </xs:annotation> <xs:restriction base="UidType"/> </xs:simpleType> <xs:element name="fieID" type="FieIDType"/> <xs:simpleType name="FieIDType"> <xs:annotation> <xs:documentation>Identification of fie </xs:documentation> </xs:annotation> <xs:restriction base="UidType"/> </xs:simpleType> <xs:element name="fumID" type="FumIDType"/> <xs:simpleType name="FumIDType"> <xs:annotation> <xs:documentation>Identification of Fum </xs:documentation> </xs:annotation> <xs:restriction base="UidType"/> </xs:simpleType> B) The other approach has me simply declaring each element. <xs:element name="fooID" type="UidType"> <xs:annotation> <xs:documentation>Identification of foo. </xs:documentation> </xs:annotation> </xs:element> <xs:element name="feeID" type="UidType"> <xs:annotation> <xs:documentation>Identification of fee </xs:documentation> </xs:annotation> </xs:element> <xs:element name="fieID" type="UidType"> <xs:annotation> <xs:documentation>Identification of fie </xs:documentation> </xs:annotation> </xs:element> <xs:element name="fumID" "UidType"> <xs:annotation> <xs:documentation>Identification of Fum </xs:documentation> </xs:annotation> </xs:element> Question: Why would I choose (A) or (B)? SO far, I can find that in many code bases, in the first, I can’t say this.FooID = that.FeeID but must instead say something like this.FooID = cast(that.FeeID ).to FooIDType (varies on language, implementation, of course) This may be god if a FooId should never be a FeeId but may be bad in other cicumstances. Is this more than a style concern?Are there deeper concerns I am overlooking? Thanks tc “The single biggest problem in communication is the illusion that it has taken place.”
|