Datalink feedback II: RESOURCE type
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Mon Mar 24 02:41:51 PDT 2014
[re-crossposting to DAL and Apps -- may I suggest to continue this
discussion on DAL?]
On Fri Mar 21 06:02:33 PDT 2014, Pierre Fernique wrote:
> Le 21/03/2014 10:28, Markus Demleitner a écrit :
> > An obvious alternative might be to use utypes (and then
> > type="metadata")
>
> Hi Markus,
> Your alternative seems very attractive ;-) My point: Is it
> reasonable to modify a Standard Recommendation, and its associated
> schema, just because we are reluctant to simply use an utype ?
Uh -- I've just re-read the VOTable REC and now can't explain why I
believed that VOTable claims its schema wasn't normative. It clearly
is in 1.2, and even VOTable 1.1 had a "should pass through W3C XML
Schema validators without error".
After that, I'd say type="service" is dead. I'm not quite sure what
to make of type then, but that's not a matter for datalink.
The service definitions then clearly must have type="metadata", but
I'd claim that's not enough to make the robustly identifiable by
datalink clients.
The good way to handle this situation was IMHO to complete the data
model Gerard and I had proposed in Waikoloa (the VO-DML for a service
description is already there), as mentioned in
http://wiki.ivoa.net/internal/IVOA/InterOpSep2013DAL/datalink-gavo.pdf
While I maintain that's where we *should want* to go (and it would
also give us all the expressiveness needed for the representation of
complex data types in the service signatures). However, pushing this
in through the fairly trivial issue of identifying service resources
would seem extremely odd, and this seems a bad time to restart proper
data modelling for datalink.
Fortunately, the VO-DML serialization is done in a way that we can
stuff into the RESOURCE's utype whatever we want and a proper
annotation, when we add it later, won't be compromised.
So, I'd suggest we just identify service descriptions with:
<RESOURCE type="metadata" utype="adhoc:service">
...
I'd prefer a prefix "adhoc" to, say, "datalink" (or anything like
that) here to ward against later human confustion when we actually do
something sensible with the datalink "prefix". But if you'd strongly
prefer datalink here (or anything else), it'd work as well: VO-DML
engines will ignore utype on RESOURCE anyway, and so no name clashes
are possible.
Cheers,
Markus
More information about the dal
mailing list