SimpleDALRegExt issues

[Ray Plante]

Hi folks,

For you folks at home, I'd like to offer a report from the discussion 
of the SimpleDALRegExt document (for general info about SimpleDALRegExt, 
see http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SimpleDALRegExt; 
for my slides see 
http://www.ivoa.net/internal/IVOA/InterOpOct2011Registry/RegExt-IVOAOct11.pdf).  
I highlighted some issues, and we came to some concensus in the room; 
however, I would like to share the discussion more widely and allow 
others to chime in. 

There are two issues to resolve before we can go to RFC, both having 
to do with the SSA extension (both raised by Markus Demleitner).  

  1. recommended namespace prefix
  2. what happened to <supportedFrame>?  

1.  Recommended namespace prefix

The document recommends use of a particular namespace prefix for these 
extensions.  (See my slides for a reminder of why we do that.)  For the 
SSA extension we have traditionally used "ssa".  Markus pointed out 
that the SSA spec recommends/requires using "ssa" as a namespace 
prefix for utypes from the SSA data model.  Common (but not 
standardized, I believe) practice is to declare the prefix as an XML 
namespace with referencing utypes within XML (see the IVOA Note, 
"UTypes and URIs").  This will collide with the registry's use when 
publishers attempt to set utypes in the descriptions of tables.

It was proposed that the easy solution would be for SimpleDALRegExt to 
recommend the use of "ssap" as the namespace prefix for the SSA 
extension.  While there was discussion of the "properness" of the DM 
use, the group approved this change.  

2.  What happened to <supportedFrame>?

A previous version of the SSA extension schema included a 
<supportedFrame> element used to declare what coordinate reference 
frames the service supports as part of the input to the POS parameters 
(see section 4.1.1.1 of the SSAP standard).  In my original attempt 
to support this, systems were identified by a URI; upon later 
examination, I saw that this raised several issues (see my slides for 
details).  I ended up dropping the element altogether rather than try 
to fix it.  

Upon re-examination, I thought that it is probably important to 
include this in the extension.  That is, if a service supports, say, 
GALACTIC coordinates, it needs some way of informing clients of such.  
Note that it appears that the SSA spec requires support for the 
default (and that was ultimately our interpretation of the spec); 
however, I would say that the wording is unclear.  What it should have 
said on this front was a matter of debate; nevertheless, what it 
actually says has a bearing on how we report frame support.  

Presented were four options to address this issue:

  0.  Drop <supportedFrame>: don't support reporting supported frames
  1.  support <supportedFrame>: values taken strictly from the list of 
      words specified in the SDM/STC which can be used directly in the 
      POS input.
  2.  support <supportedFrame>: values can be any string token, but 
      specify the list given by SDM/STC as having reserved meanings;
      this support non-standard frames but with no standard way to  
      document the meaning of those frames.  
  3.  support <supportedFrame> with values given as URIs, with 
      documentation provided via StandardsRegExt definition, and 
      predefined URIs for the list given b SDM/STC.

There some support expressed for all of these at some level, but 
concensus gravitated to option #1.  Simplicity was the primary 
motivation with the added observation that it is far from clear 
whether there would be any use of non-standard frames (let alone 
whether the SSA spec actually allows it).  

There was a second related question: how should support for ICRS, the 
default, be expressed?  The options we consider assumed that support 
for ICRS is required:

  1.  Require one entry indicating ICRS support 
  2.  Allow it to be specified; otherwise just assume it.
  3.  Do not allow one to specify support for ICRS.

All three options had some support in our group, but after a vote of 
the room, the preference was for option #1.  The rationale was
  o  it makes things clearer and consumption easier
  o  if the spec should change in the future to make support for ICRS 
       optional (as some felt it should), this extension need not be 
       changed.  

Feel free to jump into the debate of any of these issues.  If there is 
none, I will revise the documents assuming the concensus of the folks 
in the meeting.  

cheers,
Ray