Datatypes R2 Issue 38

Introduction

Type substitutability rules in schema may not match those in the abstract spec.

For example, in the schema, IVL<QTY> is not an extension of SET<QTY>. is this true? Well, it is close to being an extension -- IVL_PQ is an extension of SXCM_PQ in the schema. SXCM_PQ is the base datatype (PQ) plus a set operator attribute, that is used to construct sets from a sequuence of SXCM_PQ elements. However this mechanism is not the same as that used in IVL_QTY where there are explicit "high", "low", "width", and "center" attributes used to define the interval. So while an IVL can be represented as a SET in the ITS, when there is a type conversion between the two the wire format does have to change, so the type extension mechanism is not working as one would expect (semantics that can be expressed in the base type are done that way, and the extension just introduces new functionality.

Does this matter?

Discussion

Round table Thurs Q5 May 2006': ? ask on the list There are a number of issues that this raises:

Why are high, low, wdith and center not operators on SET? Just because something is discontinuous does not mean that it cannot have a high value, and certainly does not mean that this is any less interesting than the high value of a continuous interval. The description of these operators already has to address the fact that they are only valued when the IVL (SET) contains an ordered base type (and there is narrative that explains how SET_PQ is only ordered if the units are compatiable.

Should the XML over the wire be a direct serialisation of the abstract datatype properties, or should it be optomised to directly serialise those properties that are most often useful, and expect software to deal with deducing the additional properties.

The existing XML ITS has in general gone for lighter weight instances rather than direct serialisation of all abstract properties. Thus for interval not all of high, low, center have been included - nor has a "wrapper" element been included for SET. I suggest that it is this latter decision that causes the discomfort - if there was a wrapper element that contained each of the SXCM components, then this wrapper could also contain high and low elements where relevant for SETs, and the relationship between sets and intervals would be more obvious.

An alternative would be to represent intervals using SXCM - this was rejected in the past as making IVL too obscure and verbose

Disposition

Closed.--GrahameGrieve 00:03, 15 June 2007 (CDT)

Other actions taken since this issue was raised have dealt with the run-time substitution issue that underlies this.

There will be considerably more detail in the both the abstract & xml its to clarify what is happening with set and interval, and that should also largely clarify this issue.

Links

Back to Data Types R2 issues