datatypes (effects all 3 WDs to some extent)

Tue Apr 1 11:46:10 PDT 2014

I don't have a whole lot of appetite to enter into this discussion,
but I wonder whether anybody has taken into account footprints
consist of composite regions.

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------

On Tue, Apr 1, 2014 at 12:27 PM, Patrick Dowler <
patrick.dowler at nrc-cnrc.gc.ca> wrote:

>
> 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.
>
> 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"
>
> or if we want VOTable to actually define new data types, eg:
>
> datatype="circle"
>
> 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. They seem to
> be correct in principle. That leaves micro-format (xtype hack).
>
> Pat
>
>
>
> 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
>>
>>
> --
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2E7
>
> 250-363-0044 (office) 250-363-0045 (fax)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140401/5736a517/attachment-0001.html>