Request for Comment: StandardsRegExt v1.0

This document serves as the RFC center for the Proposed Recommendation entitled "StandardsRegExt: a VOResource Schema Extension for Describing IVOA Standards, Version 1.0". The specification can be found at http://www.ivoa.net/Documents/StandardsRegExt/20110921/index.html.

RFC Review period: 14 Apr 2011 -- 14 May 2011. Completed
TCT Review period: 21 Sep 2011 -- 21 Oct 2011

Notes to TCT:

• RayPlante and PaulHarrison have added notes to RFC comments indicating how comments were addressed

In order to add a comment to 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 StandardsRegExt page includes three compliant sample VOResource instances that use the StandardsRegExt extension. Instances can be validated with an XML Schema validater such as the one provided with Junx (which is based on Xerxes).

Comments from the community

• Sample comment by WikiName
  • Response (by WikiName)

Comments from MarkTaylor

This document looks mostly good, and the StandardKeyEnumeration element in particular is a useful tool. I have a few comments and corrections:

1. The schema presented in Appendix A appears to be badly-formed XML. If I attempt to parse it, it chokes on ampersands in a couple of the regular expressions. They need to be escaped ("&" -> "&"). The presence of this fundamental error suggests that no testing (e.g. attempted validation of actual StandardsRegExt instances) has been done on this version of the schema -- is that the case?
   • it is just a transcription error in copying the schema text to a html representation - the schema itself at http://www.ivoa.net/xml/StandardsRegExt/v1.0 does not have this problem PaulHarrison
   • RayPlante: Note also that the posted schema has been tested against the examples given on the StandardsRegExt page. I have confirmed that the embedded schema matches the posted one (apart from some minor comment differences).
2. Section 2.3: I think there's a typo somewhere in the phrase "...IVOA identifier given by <identifier>ivo://ivoa.net/std/QueryProtocol<identifier>", but perhaps I'm just misunderstanding it
   • RayPlante: While I believe this is grammatically correct it's not necessarily understandable. I'll attempt a rewrite for clarification.
   • RayPlante: This has been rewritten in version 20110510
3. Section 3.1.1: the example at the end of this section has an endorsedVersion element with status="pr". According to the list of allowed values, it should have the value "prop" instead. However, it might be better to change the list of allowed values to rec/pr/wd rather than rec/prop/wd, for consistency and to match usual IVOA usage.
   • RayPlante: I agree that we should change the schema to match the IVOA usage.
4. The StandardKey/description element is declared with type xs:token, which as I understand it means that it can't contain line breaks etc. That's OK, but probably the documentation should point out that it's for a short description so people know that a multi-paragraph entry is not appropriate. Or, define it as some other data type (xs:string) suitable for longer descriptions.
   • RayPlante: Just to be clear, the xs:token type does not recommend or imply anything about the length of the value. (And when it comes to documentation, IMHO, more is usually better than less. ) It was chosen so that (a) authors would not worry about superfluous spacing, and (b) consumers would feel free to re-format the content in a manner appropriate to the presentation. That said, multi-paragraph entries would not be appropriate because any use of space to discriminate paragraphs would be obliterated under xs:token processing.
   • RayPlante: A comment was added in version 20110510
5. Miscellaneous typos:
   • "The Virtual Observatory (VO) is general term..."
   • "...standards would represented via..."
   • "...schema call StandardsRegExt which allows..."
   • "complient"
   • "...onto IVOA identifier associated with..."
   • "...VOResource standard the defines extra..."
   • "...a controlled sets of..."
   • "...is that growing list of allowed names..." (-> growing the list?)
   • "...it is the practice VOResource..."
   • "...as a resource available via an IVOA-compliant registry..." (-> a resource is available?)
   • "... if there is only one standard ce, role..."
   • "An applications can..."
   • "...dereferencing in not necessary..."
     • corrected in latest draft PaulHarrison
6. Document processing: the section numbers appear twice in section headings (e.g. "3.1.2. 3.1.2. ServiceStandard")
   • there was some javascript that was auto-numbering as well - this has been removed in latest draft PaulHarrison

-- MarkTaylor - 28 Apr 2011

Comments from TheresaDower

A meta-comment, perhaps. Are there and should there be plans for an IVOA-maintained Registry-of-Registries-included publishing registry for physically storing these standards resources as they are written? I can see some benefit in various registries' pretty-print resource views being able to display these as linked from the resources of the standards types they describe.

-- TheresaDower - 12 May 2011

• RayPlante: yes, records for IVOA standards will be stored in the Registry-of-Registries.

Comments from TCG member during the TCG Review Period: 21-September-2011 - 21-October-2011

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)

One substantial oversight:

• My point 3 made above, about the use of "pr" or "prop" in the EndorsedVersion status attribute, though answered by Ray's comment, has not been fixed in the document (the example is not consistent with the definition).

There are also a few typos in the current version:

• Section 1: "compliment service instances" should read "complementary service instances" (note spelling).
• Figure 1 is missing in the PDF version.
• The reference [Arch] in section 1.1 looks like it should be a hyperlink, but is not.
• Section 2.2, definition of vstd:StandardKeyEnumeration: "definitions stand" should be "definitions to stand".
• Section 2.3: "defining metadata to restrict" should be "defining metadata is to restrict".
• Section 2.3: I think in <identifier>ivo://ivoa.net/std/QueryProtocol<identifier> the second tag should be a close tag ( </identifier> ).
• Section 2.3, Note box: "the only the" should be "only the".
• Section 3.2, vstd:StandardKey schema box, xs:pattern value attribute: the & is unescaped here, it should be escaped ( & ) as in the schema itself.

Assuming the authors do something about these, Apps recommends acceptance.

-- MarkTaylor - 27 Sep 2011

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, Roy Williams)

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)