utypes: a proposal

[Paul Harrison]

Here's my h'pennies worth - having not unfortunately had the benefit  
of listening to the debate in detail, but only reading the  
presentations...

On 2008-10 -30, at 15:59, Douglas Tody wrote:

> Hi Norman -
>
> On Thu, 30 Oct 2008, Norman Gray wrote:
>> ...presuming some 'cha' namespace declaration.  Making utypes
>> compatible with XPath ends up looking pretty much like the existing
>> proposal, except that '.'  -> '/' and the namespace prefix is  
>> repeated.
>
> If I understand this correctly, you are suggesting changing the
> basic syntax of UTYPE to replace the "." delimiters with the XPath
> "/".  We cannot contemplate such a change at this point as UTYPE has
> been in use for several years now, is specifed in existing standards
> such as SSA and Spectrum (at least), and is used in many production
> services and applications.

Granted that SSA and the spectrum data model has defined a number of  
UTypes, and they have been passed as standards, but this whole  
discussion would not be happening if everyone was absolutely clear  
about what a UType was, and whether the current practice is fit for  
purpose. The best that we have for a definition is Jonathan's note http://hea-www.harvard.edu/~jcm/vo/docs/utype/ut2.pdf 
  - but I think that he would agree that document has loose ends.

> 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.


Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank