TWiki> IVOA Web>SimpleDALRegExt10RFC (revision 5)EditAttach

Request for Comment: SimpleDALRegExt v1.0

This document serves as the RFC center for the Proposed Recommendation entitled "Describing Simple Data Access Services, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/SimpleDALRegExt/20120517/.

RFC Review period: May 23, 2012 - June 27, 2012
TCG Review period:
Exec Approved for REC:

To add a comment on the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the Resource Registry mailing list, registry@ivoa.net. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

Notes on Implementations and Validaters

The SimpleDALRegExt page includes several compliant sample VOResource instances that use the extension schemas defined in the spec.. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes).

Previous versions of the extensions for ConeSearch, SIA, and SSA, which the PR versions are backward-compatible with, have been in production use by IVOA-compliant registries for several years.

Comments from the community

Comments from MarkTaylor

A couple of comments about the schema:

  • Data types: Several quantities are declared as xs:int type, for instance the sia:SIACapRestriction maxFileSize and maxRecords elements. Is this intentional? xs:int is a 32-bit quantity, which at least for maxFileSize seems like an unnecessary/unwise restriction. xs:positiveInteger or xs:unsignedLong might be more appropriate. Elsewhere xs:float and xs:double are used in different places, e.g. siaSkyPos uses xs:double and sia:SkySize uses xs:float. Is there a rationale for which floating point type is used where?
  • Required elements: Most of the limit-type elements (maxRecords, maxFileSize) are declared as required. Is this a good idea? Some services may have no hard restriction on the number or size of data returned, or may not know at capability specification time what such limits are. In that case services will have to make something up, e.g. 999999999, which may make clients think that a particular limit exists when it doesn't really. Any reason not to make most of these optional? slap:maxRecords seems particularly anomalous: the table in sec 3.4.2 notes that this element is required, and also that if it is not specified there is no predefined hard limit.

And some minor comments on the text, mostly typos:

  • Abstract: "describe a services" -> "describe a service"
  • Abstract: fundemental -> fundamental
  • Abstract: Stadard -> Standard
  • Sec. 1: "... form a query ... and send it to all konwn services which support that protocol". For cone search at least this is rather a bad idea and not to be encouraged (tools like AstroScope provided, then deprecated this facility), since it submits far too many queries to be scalable or useful. This point could be rephrased to discuss sending the same queries to a moderately-sized group of compliant services matching some additional selection criteria.
  • Sec. 1: "can be search in one query" -> "can be searched in one query"
  • Sec. 1: "supports one of the protocol" -> "supports using one of the protocols"
  • Fig. 1 caption: "SimpleDALExt" -> "SimpleDALRegExt" (twice)
  • Sec. 2: Missing close parenthesis following "extension schema [VDS]"
  • Sec. 2: "unambiguosly" -> "unambiguously"
  • Sec. 3: "each extension schema have" -> "each extension schema has"
  • Sec. 3: "fixes the value its standardID" -> "fixes the value of its standardID"
  • Sec 3.1.2: "cs:ConeSearch type is vr:Capability sub-type" -> "cs:ConeSearch type is a vr:Capability sub-type"
  • Sec 3.1.2: "The custom metadata that the sia:ConeSearch type provides" -> "... cs:ConeSearch ..."
  • Sec 3.1.2 metadata elements table: the Comments written under the testQuery element should be in the verbosity section instead
  • Sec 3.1.2.1: "at least matched record" -> "at least one matched record"
  • Sec 3.2.2: "cs:SIACapRestriction" -> "sia:SIACapRestriction"
  • Sec 3.2.2.2: "axes may not particularly parallel" -> "axes may not be particularly parallel"
  • Sec 3.2.2.2: "latitdude" -> "latitude"
  • Sec 3.3.2: "is vr:Capability sub-type" -> "is the vr:Capability sub-type"
  • Sec 3.3.3: "for compliance final SSA Recommendation" -> "for compliance with the final SSA Recommendation"
  • Sec 3.4.1: "The namespace prefix, sia" -> "The namespace prefix, slap"
  • Sec 3.4.2: "The sia:SimpleLineAccess type" -> "The slap:SimpleLineAccess type"

-- MarkTaylor - 19 Jun 2012




Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)

Applications Working Group (Mark Taylor, Enrique Solano)

Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)

Data Model Working Group (Jesus Salgado, Omar Laurino)

Grid & Web Services Working Group (Andreas Wicenec, Andre Schaaff )

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

Semantics Working Group (Sebastien Derriere, Norman Gray)

VOEvent Working Group (Matthew Graham, John Swinbank)

Data Curation & Preservation Interest Group (Alberto Accomazzi)

Knowledge Discovery in Databases Interest Group (Giuseppe Longo)

Theory Interest Group (Herve Wozniak, Franck Le Petit)

Standards and Processes Committee (Francoise Genova)


Edit | Attach | Watch | Print version | History: r28 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2012-06-26 - root
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback