From greene at stsci.edu  Mon Oct 10 12:13:24 2011
From: greene at stsci.edu (Gretchen Greene)
Date: Mon, 10 Oct 2011 19:13:24 +0000
Subject: Pune registry meeting sessions
Message-ID: <F4391FEBF3C01E499F244DFA4B689A6B086A715A@EXCHMAIL2.stsci.edu>

Hi RWGr's,

The registry sessions are currently setup on the IVOA meeting program.  See the following link

   http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/InterOpOct2011<http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/InterOpOct2011Applications>Registry

for the schedule.  Let me know if you have any additions or changes and either myself of Pierre will make
adjustments where possible.  I have not set time limits for the talks,  yet please keep your presentation topics to
15 min to allow time for discussion.

Pierre will be coordinating the sessions,  i will hope to Skype in if the connections permit.

Enjoy Pune!

Gretchen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20111010/a7783b7d/attachment.html>

From rplante at ncsa.uiuc.edu  Sun Oct 16 22:23:51 2011
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Mon, 17 Oct 2011 00:23:51 -0500 (CDT)
Subject: updated StandardsRegExt document on TWiki
Message-ID: <alpine.DEB.2.00.1110170017280.3812@epte>

Registry WG,

I've updated the StandardsRegExt document on the TWiki page, 
StandardsRegExt 
(http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/StandardsRegExt) to 
address TCG review comments from Mark and Sebastien.  With kind 
permission from the Chair and Vice-Chair, we can send this to the 
document repository for Exec review on Wed.  

cheers,
Ray


From greene at stsci.edu  Tue Oct 18 07:09:06 2011
From: greene at stsci.edu (Gretchen Greene)
Date: Tue, 18 Oct 2011 14:09:06 +0000
Subject: updated StandardsRegExt document on TWiki
In-Reply-To: <alpine.DEB.2.00.1110170017280.3812@epte>
References: <alpine.DEB.2.00.1110170017280.3812@epte>
Message-ID: <F4391FEBF3C01E499F244DFA4B689A6B086A8092@EXCHMAIL2.stsci.edu>

Ray,  

Thank you for your excellent work in polishing the document.  You have my approval to send this forward to the exec review!

Cheers, Gretchen
________________________________________
From: registry-bounces at ivoa.net [registry-bounces at ivoa.net] on behalf of Ray Plante [rplante at ncsa.uiuc.edu]
Sent: Monday, October 17, 2011 1:23 AM
To: IVOA Registry WG
Cc: Sebastien Derriere
Subject: updated StandardsRegExt document on TWiki

Registry WG,

I've updated the StandardsRegExt document on the TWiki page,
StandardsRegExt
(http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/StandardsRegExt) to
address TCG review comments from Mark and Sebastien.  With kind
permission from the Chair and Vice-Chair, we can send this to the
document repository for Exec review on Wed.

cheers,
Ray


From rplante at ncsa.uiuc.edu  Wed Oct 19 11:12:22 2011
From: rplante at ncsa.uiuc.edu (Ray Plante)
Date: Wed, 19 Oct 2011 13:12:22 -0500 (CDT)
Subject: SimpleDALRegExt issues
Message-ID: <alpine.DEB.2.00.1110190710340.3812@epte>

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