Datalink feedback II: RESOURCE type

[Mark Taylor]

I've added a placeholder note in the
http://wiki.ivoa.net/twiki/bin/view/IVOA/VOTableIssues13
wiki page about the value range of the RESOURCE/type attribute.
The existing restriction does seem a bit arbitrary.  I don't know
that there's a strong case for changing it, but it's there in
case we want to discuss it later.

On Fri, 21 Mar 2014, Markus Demleitner wrote:

> Dear DAL group, Dear Apps group
> 
> I crosspost this as this is largely a VOTable issue.  Also, this is a
> welcome opportunity to point people not on the DAL list to 
> http://www.ivoa.net/pipermail/dal/2014-March/006734.html -- I
> consider the question of fixing suboptimal VO practices in service
> parameter form *really* important and highly relevant to Apps, too,
> so let me cordially invite you to comment there, too.
> 
> The issue at hand: The current Datalink WD says services are to be
> described in elements like
> 
> <RESOURCE type="servce">...</RESOURCE>
> 
> It turns out RESOURCE type="service" may not be VOTable-legal.
> 
> Actually, it's a bit tricky.  In VOTable, the schema is not
> normative, the spec text is.  Here is what it has to say about type:
> 
>   [A RESOURCE] may also be qualified by type="meta", meaning that the
>   resource is descriptive only, i.e. does not contain any actual data: no
>   DATA element should exist in any of its sub-elements. A RESOURCE without
>   this attribute may however have no DATA sub-element.
> 
> The text does not mention type="results" at all as far as I can tell.
> 
> On the other hand, the schema says type defaults to results, which means
> that technically, the type="results" thing we have in our DAL responses
> wouldn't be necessary at all *if* we took the standard seriously.
> 
> My take: The situation is confused enough to say the restriction on
> type should be lifted in the schema with the next VOTable release,
> presumably together with the default specification that nobody should
> have relied upon in the first place.  Meanwhile, the normative text
> doesn't keep us from using type="service", so I'd say we're fine.
> 
> An obvious alternative might be to use utypes (and then
> type="metadata"), but I'd much prefer if we could keep improvised
> utypes out of datalink until there's clearly no choice.
> 
> Cheers,
> 
>           Markus
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/