Comments on SkyNodeInterface PR

[Inaki Ortiz]

Hi there

Please find below a few comments on the SkyNode Interface Working Draft
v1.00.

1. Implementation of Standard Interface (page 4, QI-1)
------------------------------------------------------

The specification forces to implement interfaces outlined in the WD
Standard Interface v1.0: "MetaData", "MetaDataChangeOn", "HeartBeat" and
"HarvestLog". The SkyNode-v1.0.wsdl file wraps some of these services
(not all of them) in a common interface so called "GetAvailability".

If the Standard Interface is a MUST we have to include all these
services in the WSDL file as the Standard Interfaces document suggest on
page 2, paragraph 2.1 and get rid of the GetAvailability. 

Nonetheless I believe that implementing the Standard Interface is a bit
too much. As far as I know none on the fully operational SkyNodes do it
and this requirement has been present since the very beginning in the
SkyNode Interface specification. 

Is the GetAvailability enough for the time being? If so we should state
it clearly in the specification.

2. Tables interface  (page 6, QI-3)
-----------------------------------
According to the specification "[...]The MetaTable SHOULD have the
TableName, a description, The Primary Key, approximate Row Count, Rank,
XmatchRegion [...] and a set of Relation which list ForeignKey and Table
pairs for related Tables".

All these elements are present in the MetaTable schema definition  (see
SkyNode-v1.0.wsdl file) but the XmatchRegion. Should we append a new
element to the MetaTable complex type to handle this? I guess..

3. Columns interface  (page 6, QI-4)
------------------------------------

According to the specification "[...]This SHALL return an array of
MetaColumns this structure SHALL contain the Column Name, Data Type (as
in SQL type), Unit, ByteSize(number of bytes), Precision (number
significant digits), Description, Rank and UCD".

I believe DataType definition is too loose. It should be defined in a
more restrictive way than an String element. Otherwise the data type
metadata returned by this interface would not be of very much use. We
all know that the sql data types are pretty dependant on DBMS vendors so
we should agree on a fixed list of data types (to be mapped by all
SkyNode implementors according to the database manager server they use).

Besides this the minimum multiplicity of Name, Unit, Description, UCD
and DataType is set to 0 (see SkyNode-v1.0.wsdl) where according to the
spec it should be set to 1 (minOccurs=1, maxOccurs=1). Remember that
according to the IETF (RFC 2119) SHALL  means "required"!!

4 Full SkyNode requirements  (page 5, QI-11)
----------------------------------------------

If supporting complex shapes is a MUST we should re-phrase or update the
Feature Matrix on top of page 5. Circular Region Search support is not
enough for full SkyNodes!

5. XMatch issues (pages 7, 8)
-----------------------------

"A particular node may decide to implement this differently however if
the chi-square parameters are not returned then other nodes wishing to
use the above algorithm will not function correctly" (page 8, QI-12)

We already gave our inputs on this issue in Kyoto, and thus summarize
them below for reference.

We believe there is a lack of information in the specification about the
way SkyNodes should interface/communicate with each other in order to
perform a XMatch between catalogs. We should be aware that this
communication depends strongly on the algorithm used. 

In principal any XMatch algorithm using XYZ coordinates returns not only
the chi-square but the coordinates matching the ADQL query as well. This
obviously forces the next node in the plan to support cartesian
coordinates to perform the cross matching. If the second node in the
chain has implemented such an algorithm by using standard astronomical
coordinates (right ascension and declination), then it would have to
support the conversion from XYZ to Ra,Dec (and the other way around as
the output to the next node, if present, must be in cartesian coodinates
too!). 


Well, that is all from my side

Cheers


-- 
________________________________________________________

 Iñaki Ortiz de Landaluze
 Software Engineer
 ESA/ESAC
 European Space Astronomy Centre
 P.O. Box 50727, 28080 Madrid - Spain
 Tel: +34 91 813 13 67
 E-mail : Inaki.Ortiz at esa.int
_________________________________________________________