XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Style, Substance and Typing in Schemas

Win32 programs used to (do) take the approach described in (b) for 
referencing handles to objects.  Even though all the handles were basically 
integers, they were wrapped in their own strongly typed struct so that you 
couldn't pass, say, a window handle to a function expecting a memory handle.

I suspect there is no right or wrong answer to this.  Approach (b) likely 
involves more effort though, so I guess I'd start out using approach (a) 
until evidence suggested that something like (b) was require.

Hope that's some help!

Original Message From: "Andrew Welch"

Why would you want two or more types that are identical in all but name?

ps. why post all the annotations?


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.”
> – George Bernard Shaw.****
> ------------------------------
>
> Toby Considine
> TC9, Inc****
>
> TC Chair: oBIX & WS-Calendar****
>
> TC Editor: EMIX, EnergyInterop****
>
> U.S. National Inst. of Standards and Tech. Smart Grid Architecture
> Committee
>
> ****
>
>   ****
>
> Email: Toby.Considine@gmail.com <Toby.Considine@fac.unc.edu>
> Phone: (919)619-2104****
>
> http://www.tcnine.com/
> blog: www.NewDaedalus.com****
>
> ** **
>
> ** **
>



Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS