Hi there
Please find below a few comments on the SkyNode Interface Working Draft v1.00.
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)
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 _________________________________________________________Received on 2005-06-13Z15:56:39