[Rets-dev] Technical: A proposed solution to some issues around mixed data types and RETS schemas

[Jeff Brush]

Paul,

Any ideas how XML data binding tools would respond to this? 

Sometimes the tools can generate code that is a little convoluted (and
unexpected), but should that be a consideration?

I can look into it if you like... Or someone else can volunteer, data
binding is a good thing to learn if you are doing a lot of XML...

Jeff

> -----Original Message-----
> From: rets-dev-bounces at rets.org 
> [mailto:rets-dev-bounces at rets.org] On Behalf Of Paul Stusiak
> Sent: Wednesday, May 02, 2007 4:25 AM
> To: E-mail Rets-Dev
> Subject: [Rets-dev] Technical: A proposed solution to some 
> issues around mixed data types and RETS schemas
> 
> Having just sent out an email suggesting we skip typing for 
> the present, I will now perform an apparent about face.
> 
> Over the last week or so, in my abundant spare time, I have 
> been looking at resolving the general problem of typing mixed 
> types. An example of this is the age of the house.
> 
> A natural typing for this would suggest that it is an integer 
> representing the number of years since the house was built. 
> There are the two counter examples of the house age described 
> as "new" and an older house where the age is undetermined, 
> but it is an "old-timer". 
> While there will be outliers to these three cases - age as a 
> number, new (locally defined rule on what is new) and old or 
> old-timer (locally defined rule on what is old), I think that 
> this represents a useful set of data for someone trying to use it.
> 
> I'm sure that examples can be offered of cases where the age 
> or other value is offered in a range or other representation, 
> however, the case under discussion is limited to values that 
> also have certain well-defined or well-known values of a 
> descriptive nature.
> 
> Let us assume that there is an element defined in a container like so
> 
> <ns1:Container>
>     <ns1:Age type="commons:Age"/>
> </ns1:Container>
> 
> The text book solutions would be to define it as currently in 
> Primitives.xsd like so
> 
>     <xs:complexType name="Age">
>         <xs:annotation>
>             <xs:documentation>
>                 The age, in years, of a structure.
>             </xs:documentation>
>         </xs:annotation>
>         <xs:simpleContent>
>             <xs:extension base="commons:SecureInteger"/>
>         </xs:simpleContent>
>     </xs:complexType>
> 
> This would permit instances like
> <ns1:Container><ns1:Age>8</ns1:Age></ns1:Container>
> but would fail instances that did not have an integer, 
> including the empty string.
> 
> While a solution could be constructed to apply attributes 
> where the age was new or old-timer, an alternate may be tidier.
> 
>      <xs:simpleType name="empty-string">
>         <xs:annotation>
>             <xs:documentation>
>                 A primitive type used to permit null values, 
> represented
>                 by the empty string, for data types other than the
>                 xs:string type. Combined with the base data type in a
>                 union, the custom data type can permit 
> validation of the
>                 XML instance document where the underlying type is
>                 integer for example. In that case, the values 
> permitted
>                 are any integer OR the empty string.
>             </xs:documentation>
>         </xs:annotation>
>         <xs:restriction base="xs:string">
>             <xs:length value="0"/>
>         </xs:restriction>
>     </xs:simpleType>
> 
>     <xs:simpleType name="nullable-integer">
>         <xs:union memberTypes="xs:integer commons:empty-string"/>
>     </xs:simpleType>
> 
>     <xs:simpleType    name="age-enum">
>         <xs:annotation>
>             <xs:documentation>
>                 An enumeration of additional data values
>             </xs:documentation>
>         </xs:annotation>
>         <xs:restriction base="xs:string">
>             <xs:enumeration value="New"/>
>             <xs:enumeration value="Old"/>
>         </xs:restriction>
>     </xs:simpleType>
> 
>     <xs:simpleType name="simple-age">       
>             <xs:union memberTypes="commons:nullable-integer
> commons:age-enum"/>
>     </xs:simpleType>
> 
>    <xs:complexType name="Age">
>         <xs:annotation>
>             <xs:documentation>
>                 The age, in years, of a structure.
>             </xs:documentation>
>         </xs:annotation>
>         <xs:simpleContent>
>             <xs:extension base="commons:simple-age">
>                 <xs:attribute    ref="commons:isgSecurityClass"
>                                     use="required"/>
>             </xs:extension>
>         </xs:simpleContent>
>     </xs:complexType>
> 
> This would permit validation of values like 
> <ns1:Container><ns1:Age>8</ns1:Age></ns1:Container>
> <ns1:Container><ns1:Age></ns1:Age></ns1:Container>
> <ns1:Container><ns1:Age>new</ns1:Age></ns1:Container>
> <ns1:Container><ns1:Age>old-timer</ns1:Age></ns1:Container>
> 
> while failing validation of
> <ns1:Container><ns1:Age>1/4</ns1:Age></ns1:Container>
> 
> The short explanation is that we create a union of three 
> things - integers, empty strings and the values new or 
> old-timer. The validation engine is then able to use this 
> information to compare the instance value with that defined 
> in the schema.
> 
> The example uses Age, but there are probably other cases or 
> additional values that could be used.
> 
> Since I have already done the work, it seemed useful to post 
> this so it doesn't get lost and to attract some comments.
> 
> I think that there are a couple of solutions to picklists 
> that one of us will post in the coming days for the same reason.
> 
> Comments and questions are welcomed.
> 
> Back to your regularly scheduled message...
> 
> --
> Paul Stusiak
> Falcon Technologies Corp.
> 
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev
>