Request for Comment: SimpleDALRegExt v1.0This 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, 2012TCG 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 ValidatersThe 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 communityComments from MarkTaylorA couple of comments about the schema:
Comments from TheresaDower(pardon any major formatting issues; twiki is not being kind to my preview/editing attempts) I will admit I am unsure how much this document is supposed to be an administrative collation of the existing standards and how much we intend to change each of them with an eye on backward compatibility. This may or may not be the stage at which to address inconsistencies between the standards, but I can't think of a better one. (It may also be well past time, as I note we've already gone over the RFC date but are requesting more feedback.) * For example, the Cone Search test query is required. It is not required for any of the other service types. (Sec 3.2.1:) In practice, I have seen registered cone searches handle this by populating testQuery with bogus values, leading to non-responsive test queries. In practice, I've also seen validators fail non-Cone Search services 100% fullstop for having no optional testQuery. * Likewise, SSA's (Sec 3.3.2)) maxFileSize is optional, SIA's is required, and it's often populated with an intentionally meaningless value of 0. * I know there have been and continue to be good reasons for encouraging data/service providers to provide more and more metadata as the standards grow in complexity, but if there is a time to look back and make a consolidated standards document more internally consistent between standards, this is it. * These comments are obviously related to MarkTaylor's general ones about the creeping number of required fields. Many of these values are difficult or impossible for service providers to calculate for some catalogs and thus many of these fields get filled with bogus information, which is less than useless to validators and client software. (If I have understood RandyThompson's offline comments correctly, Sec 3.2.2: sia:MaxImageSize/Extent stand out as a particularly difficult example for large catalogs with variably rotated images from different instruments.) Even if we don't want to tackle every field in each standard right now, it would be good to look at some of these and either make them optional or provide guideline default values in more cases than we already do. -- TheresaDower - 23 Jul 2012 | ||||||||
Added: | ||||||||
> > |
Comments from Randy ThompsonComments and questions (as sent to Ray last month) * General:
"The sky coordinate axes may not particularly parallel with the image axes (e.g. due to rotation or projection effects); in this case, the longitudinal side should be considered the side of the image that it cuts the smallest angle with."Why not just define maxImageSize as the x,y dimensions in pixels of the largest image that can be requested? I suspect this is what most data providers do anyway.
"A VOResource resource description must not include both a ssap:SimpleSpectralAccess capability and a ssap:ProtoSpectralAccess capability that describe the same service base URL, as given by the <interface>'S<accessURL>."I'm not sure what "<interface>'S<accessURL>"means, but does this sentence imply our services are no longer allowed? -- RandyThompson - 05 Aug 2012 | |||||||
Comments from TCG members during the TCG Review Period: ?? ???? 2012 - ?? ???? 2012WG 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)<--
|