rplante at ncsa.uiuc.edu
Wed Oct 19 11:12:22 PDT 2011
For you folks at home, I'd like to offer a report from the discussion
of the SimpleDALRegExt document (for general info about SimpleDALRegExt,
for my slides see
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 184.108.40.206 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
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
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.
More information about the registry