Sorry, answered too fast. So: · Uid could be abstract, and I could be enforcing substitution. (Choose one fo these derived types for this location) · I could be identifying Actors and Roles in a complex e-commerce scenario, in which I may have the same Actors (common underlying identity) typing into different roles, and in which I want role enforcement across multiple elements · I could be identifying documents (generic reference identifier) but want to enforce type of document for certain other elements of the information model (POs, Quotes, Lading, Memos,…) If the only issue is “can I render it in XML and find it in Javascript” then I have one type of answer. In that case, type them all as strings, and do it all in place and not create the types. I get that, and the attraction of that. Here I am trying to create an abstract information model which is the declarative basis behind creating the larger and more complex message exchanges. Perhaps that means the rule is “All one type unless you are willing to go all the way to polymorphism and substitutionGroups”, Those seemed to heavyweight, but maybe they are the right answer. tc "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -Antoine de Saint-Exupery
From: Andrew Welch [mailto:andrew.j.welch@gmail.com]
On 11 October 2011 15:29, Toby Considine <Toby.Considine@gmail.com> wrote: 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.”
|