utypes: a proposal

[Douglas Tody]

On Thu, 30 Oct 2008, Paul Harrison wrote:
>> To avoid changing the fundamentals of UTYPEs the main things which must
>> not change are:
>>
>>   o	The basic syntax as currently in use.
>>
>>   o	The ability to use a simple string equality comparision to
>>   	recognize UTYPEs.  Apps do not parse UTYPEs, they just use
>> 	string comparision, e.g., to recognize the fields of a data
>> 	model.  Humans "parse" UTYPEs when they read them.
>
> It seems to me that these to requirements are at odds with each other - if 
> the only requirement is that applications need to recognise each UType as a 
> string that points to a distinct place in the data model then it really does 
> not matter too much what the syntax is, as long as each data model defines 
> the mapping between string and model element. This sort of equivalence 
> actually fits well with one of Norman's earlier suggestions (he does keep 
> trying) http://www.ivoa.net/Documents/latest/utype-uri.html. Or alternatively 
> the sort of thing that Gerard suggests, when the theory data model publishes 
> UTypes with their own syntax automatically generated from the UML.

Strictly speaking you are right - so long as the strings are fixed
(e.g., not parsed expressions like XPaths) so that one can test them
easily then in principle the syntax does not matter.   But since these
are right in the user interface in all specs, published papers, the
NVO book, in user code etc. I think we should try to be consistent.
I have always felt as well that we should have simple rules for how to
generate these from the model class hierarchy (or UML if you prefer).
The rules might change slightly from current practice but we should try
to be consistent.

That said, the syntax can matter if UTYPEs are used in expressions,
e.g., in ADQL or TAP.  For example '/' is a reserved character in many
languages: numerical expressions, ISO8601 times, DAL range lists, etc.

Gerard's SimDB scheme sounds well thought out and pretty close to
current UTYPE usage but I am still not clear on why it differs at all.
I guess I need to go look at this more carefully to see why a "/" has
crept in there.

 	- Doug