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

[Paul Stusiak]

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.