Datatype comments

1. ambiguous use of length

I think that length and maxLength should be exclusively used to number of
characters used to represent the datatype.  A different term (byteCount
maybe) should be used to indicate between number of bytes used in the
machine representation of the data.  For example,

<datatype name="temperature">
	<basetype name="real"/>
	<!--  This would indicate that the representation in the XML file
should not go beyond 20 characters  -->
	<maxLength>20</maxLength>
	<!--  This would indicate that DOM access should be done as a R8
-->
	<byteCount>8</byteCount>
</datatype>

2. Additional datatype content (Warning boundaries example)

It is useful in many applications to have the concept of inviolatable
boundaries and warning boundaries.  For example, say you were doing a
thermostat temperature setting datatype.  Temperature has a lower boundary
of 0 K and no upper limit (would be limited to the largest number
expressible by the machine representation chosen).  The 0 K boundary should
be inviolate meaning that any attempt to set a temperature below absolute
zero should cause an exception.  However, it might be nice to be able to
specify a range outside of which the application should confirm the use
really meant that setting, but would not stop processing.  (I hate it when I
accidentially liquify the air in the room)

This is probably unreasonable to go into the schema spec, but what I would
like is some clean way that I could add additional content to the datatype.
I'd also want to indicate that a specific data type in a specific
dimensional unit, for example Kelvin.  With the current definition, I would
have to:

1. Have a base datatype document that I stripped warning boundaries and
dimensional units out of before presenting to a validating parser
2. Have a secondary document that linked datatypes with warning boundaries
and dimensional units

For this additional information, it would be useful to have a "<addendums>"
or "<more>" element with any content under the <datatype> element.

Received on Thursday, 1 July 1999 13:02:14 UTC