datatypes (effects all 3 WDs to some extent)

[François Bonnarel]

Hi all,
Le 01/04/2014 18:27, Patrick Dowler a écrit :
>
> I don't see how anything but some kind of syntax for the value can 
> ever provide the ability to deliver footprints/polygons as values in a 
> simple table, such as one gets when doing
>
> select s_region from ivoa.ObsCore
>
> It has a variable number of primitive values so I don't see any sane 
> way to put that in a table with primitive types.
>
I fully agree with all this
> As to what I had in mind, if we are to keep intervals, points, 
> circles, ranges, and polygons as "data types" then we would have to 
> decide if we describe them with micro-formats, eg:
>
> datatype="char" arraysize="*" xtype="circle"
>
I think this is the reasonable way to do. In the discussion in november 
, december I allready asked about doing something like this
http://www.ivoa.net/pipermail/dal/2013-November/006558.html

So now, I would say it slightly differently that I  did in november. 
Let's define names for the advanced types we need and use xtype to tell 
which one we are using in output VOTABLE (and input QUERY parameters). 
And store in an IVOA document the syntax for these types using either 
something like C-like format or best (more accurate) regular expressions.
> or if we want VOTable to actually define new data types, eg:
>
> datatype="circle"
>
I would better like, as Mark Taylor suggested not change to often the 
VOTABLE spec.
> There is a somewhat ugly middle ground using arrays, eg:
>
> datatype="double" arraysize="3" xtype="circle" unit="deg"
>
> but that way of doing things restricts one to a single primitive type 
> for "structures" so is probably very short-sighted. Still, maybe this 
> is OK for geometry and intervals.
>
> So, keeping the concept of "geometry datatypes" does not require 
> votable changes and I appreciate the arguments against such a change.
agreed
> They seem to be correct in principle. That leaves micro-format (xtype 
> hack).
>
> Pat
>
By the way in the general discussion about VO-dml and parameters types, 
I think we should distinguish between real Data models and Datatypes.
VOTABLES GROUPs mimicking Class aggregations or associations can help as 
long as it helps the software to find out it's way in the VOTABLE and 
fill the ObjectOriented structures,  but at some point having attributes 
in the classes with some elaborated "xtype" allows more flexibility in 
the usage

Cheers
François
>
> On 01/04/14 12:43 AM, Markus Demleitner wrote:
>> Hi everyone,
>>
>> On Mon, Mar 31, 2014 at 04:16:02PM +0100, Mark Taylor wrote:
>>>> Ideally, we would have a document that defines datatypes and 
>>>> serialised
>>>> values. Then ADQL-2.x would refer to that document, VOTable-1.x 
>>>> (x>3) would
>>>> need to support serialisation of values of those datatypes. TAP-1.x 
>>>> would not
>>>> have to say as much about datatypes as it does now, so it would get 
>>>> stripped
>>>> down a bit. Other DAL and DM documents could use the datatypes by 
>>>> reference to
>>>> a definitive document.
>>>
>>> I'm not sure exactly what you have in mind for the future extensions to
>>> VOTable here - your use of the term "datatype" suggests that you are
>>> proposing new primitive values of the datatype attribute alongside
>>
>> No -- while I cannot speak for Pat, that is not what I have in mind.
>>
>> The idea is fairly analogous to common programming languages, where
>> there are some primitive types (which are what REC-VOTable defines),
>> using which the programmers define their types; in C, say:
>>
>> typedef struct {
>>    double lat, lon;
>> } Point;
>>
>> typedef struct {
>>    Point *center;
>>    double radius;
>> } Circle;
>>
>> So, VOTable wouldn't need to change, much as C doesn't change by the
>> above definitions.
>>
>> The good news is that we don't have to invent a way to note down
>> these type definitions -- VO-DML, while it still needs some work to
>> smooth out the rough edges, is exactly about these definitions.
>>
>> It also contains rules how to express this in VOTable, and these are
>> written in a way that annotations can *later* be added transparently,
>> meaning we can write now
>>
>> <PARAM name="LAMBDA_MIN" id="LL"/>
>> <PARAM name="LAMBDA_MAX" id="LT"/>
>>
>> and have clean and (conceptually) simple interfaces.
>>
>> Once we decide we need clients to actually understand interfaces and
>> manipulate complex objects, all that's needed is the inclusion of
>> groups like
>>
>> <GROUP utype="Interval">
>> <PARAMRef ref="LL" utype="lowerBound"/>
>> <PARAMRef ref="LT" utype="upperBound"/>
>> </GROUP>
>>
>> (*addition* meaning naive clients would continue to work, as the
>> remaining document structure hasn't changed) -- and anything with a
>> sufficiently capable VOTable library could immediately manipulate
>> interval objects (or circles, or points, or things with reference
>> systems, or whatever) within both the service and the client without
>> any custom code, while keeping the stuff on the wire clean.
>>
>>> "boolean", "int", "float", "double" et al.  I would personally be
>>> unenthusiastic about that for the two related reasons:
>>>
>>>    (a) the other datatypes are primitive values, and something
>>>        like interval doesn't seem at the same storage level, and
>>>
>>>    (b) it means that every time we need a new datatype it means a
>>>        revision of VOTable (and updates of generic VOTable parsing
>>>        software libraries etc)
>>>
>>> My view of VOTable is infrastructure that should be capable of
>>> storing syntactically or semantically complex content without itself
>>> being syntactically or semantically complex.
>>
>> 100% agreed.
>>
>>> *If* we are going to encode more or less complex data types in
>>> VOTable I think that the xtype hack is the right way to do it.
>>
>> While I give you that it would be good to understand what xtype
>> actually is about, and I do see a role for it in "weird" quasi-atomic
>> cases (date, in particular), I think for a general type system we are
>> well advised to do what the programming language community has been
>> doing at least since the introduction of ALGOL and allow explicit
>> type declarations rather than daring combinantions of strings as
>> values and a single other string (the xtype) as annotation.
>>
>>> future versions of VOTable.  If you (Pat/Markus/list) think there
>>> is or may be something here which should get addressed in a future
>>> version of the VOTable standard, I encourage you to add a section
>>> (though by all means wait until it's clear from list discussions
>>> what it should contain).
>>
>> Currently, the VO-DML instance serialization doesn't require any
>> changes to VOTable.  Within the utypes tiger team, Gerard hinted that
>> another attribute might help a somewhat more explicit annotation --
>> basically, allowing annotating both the role and the type of an
>> entity IIRC --, but as I understand that would go under "nice to
>> have" rather than essential for the mechanism to work.  Gerard?
>>
>> Cheers,
>>
>>            Markus
>>
>