[Obscore1.1] WD comments

[CresitelloDittmar, Mark]

Markus,

I'll admit that I have always been a bit fuzzy on how ObsCore/ObsTAP ties
in with the DAL protocols.
I've been trying to review some of that today.. with limited success.


On Thu, Jul 9, 2015 at 7:39 AM, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DM,
>
> On Wed, Jun 24, 2015 at 04:07:25PM -0400, CresitelloDittmar, Mark wrote:
> > B3.5: creation date
> >    Shouldn't we update this to clarify that this is not strictly ISO
> 8601,
> > but rather, the FITS standard which is 8601 without the "Z" tag.   There
> > was a discussion on this some time ago, and that is the language folded
> > into the DatasetMetadata model (Section 6.4.1.1).
>
> Running the risk of bikeshedding, I'd like to mention that IMHO is
> the proper reference for VO data formats is DALI, section 3.1.2.
>

The DALI spec applies to DAL services only, so may be applicable for the
ObsTAP side.
But it would be TAP implements DALI (assuming it does), and ObsTAP is a
specialized TAP..

*But*, frankly I don't think data models in general should say
> anything about the serialisation of literals, as they may be
> serialised into fairly different containers, which in turn may have
> conventions of their own.
>

I think agree with you here..
This bit of info is about the string representation of that datatype in an
ObsTAP
query response.  Not part of the model proper.

>
> In the particular case of obscore, these values are going to sit in a
> relation database system, which will almost certainly *not* store a
> date as a DALI-type string -- in that sense I'm fairly sure none of
> the existing obstap servers are compliant.  Fortunately, there's no
> way a validator could get me, as it has no way to figure out what I'm
> doing behind my VOTable facade.
>
>
I'm not sure I follow.
ObsCore:Table 7 is shows that the DB Table should store the (creation_date)
element
in a manner which can be exposed as an adql:TIMESTAMP type.

ObsCore: Appendix B
I think this is not trying to define storage format, but just define the
elements,
and (especially in the case of the dates) how to express them in the query
response
since there hasn't been another document which defined that.

B3.5: I think uses the word 'stored' where it means 'expressed'
"This is a time stamp, *expressed* in ISO 8601 format,
using this specific format: (YYYY-MM-DDThh:mm::ss)"



> Anyway, after these considerations I'd propose to remove  all
> references to the storage format of dates, in particular in B.3.5 and
> B.4.5.
>


This would be fine, so long as an implementor knows how to express
the adql:TIMESTAMP elements.  Maybe this is already covered from
the TAP document?.. Section 2.5:

"TIMESTAMP values are specified using ISO8601 format without a timezone (as
in 2.3.4 ) and are assumed to be in UTC. The xtype=”adql:TIMESTAMP”
attribute must be specified in an uploaded VOTable in order for the values
to be inserted in a column of type TIMESTAMP; without the xtype, the values
would be inserted into a CHAR(n) or VARCHAR column."

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20150709/b42be647/attachment.html>