Datatypes R2 Issue 18

Introduction

Provide the ability to send a simplified representation of a GTS, in the form of an IVL_TS that includes all times included in the GTS (and maybe others).

This could be done as an outer hull – ie be included in the GTS expression – however it may be that the translation would be generated separately from the rest of the GTS – so it would be better if it could be stored separately. While my immediate requirement is for an outer hull interval – there may be other summary requirements – such as a TS that is the “central point” of the GTS, a textual rendering of the GTS, and maybe others. I would therefore suggest a generic solution would allow a translation with two components – the value (GTS) and a translationType code. The ability to share these simplified versions of the GTS has a performance benefit, and this is the main motivation for the proposal

backward compatible: This would be an additional component to a GTS, and could be ignored by systems that do to recognize it.

Discussion

The restricted case is already possible. You can write a constraint in text that it must always be populated. You can hack your schema if you want

I am anxious about this item. It is not very well specified. I can see some use cases but the "generic solution" discussed here with translation etc. frightens me. It seems not to the point. One issue discussed (outer hull) is about incomplete information. That ought to be fine. So, we need a GTS of which all we know is the outer hull. But this has nothing to do with translations nor with "simplified representations of GTS". I suggest this item be put on hold pending more specific use cases, and then likely split into multiple items. Gschadow 19:11, 13 May 2007 (CDT)

Links

Back to Data Types R2 issues