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
TCG Review period: 21 Sep 2011 -- 21 Oct 2011 Completed
Exec Approved for REC: 8 May 2012

Notes to TCG:

• 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).

An independent example of a StandardsRegExt instance document, tre-vor.xml, describing the TAPRegExp was generated by Markus Demleitner.

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 members 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)

page 2 The acknowledgements making reference to "Eurpean Commission's Sixth Framework Program via the Optical Infrared Coordination Network (OPTICON)." should probably be removed or updated with the more recent projects.

• RayPlante: After consulting the current euro-vo web page, I changed this to "European Commission's Seventh Framework Program". Let me know if there is something better to use.

page 4 The IVOA Architecture diagram is missing in the PDF version of the document. It should be added. Should we add VOResource and VODataService in this diagram ?

• RayPlante: VOResource is there, but VODataService is not. This spec is not directly dependent on the latter (though reference is made to it) which is why it was not included.

page 10 The note about SkyNode is a bit confusing. SkyNode has not been "endorsed", but it is just in WD and now has become deprecated, with TAP having become a Recommendation.

• RayPlante: Added a sentence that hopefully clarifies (see pending version). The note highlights this very fact as an example of the use of "deprecated": even though SkyNode has been deprecated, services still do exist and publishers can and should register them if they are still useful. In that registration, they can identify it as a SkyNode via the standardURI attribute. It's therefore helpful to have a SkyNode standards record; however, that record should be marked deprecated and refer readers to TAP.

page 19 The reference [ID] should make reference to the latest version 1.12 (http://www.ivoa.net/Documents/latest/IDs.html) The reference [VDS] to VODataService should be the reference to the Recommendation, not to the ProposedRecommendation

• RayPlante: fixed (in pending version). Thanks!

I approve the document, provided the above mentioned updates are taken into account.

-- ChristopheArviset - 22 Nov 2011 (apologies for the late inputs)

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).
  • RayPlante: Ack! Sorry about that. I've updated this in the pending version

There are also a few typos in the current version:

• Section 1: "compliment service instances" should read "complementary service instances" (note spelling).
  • RayPlante: This was really supposed to be "compliant"; fixed accordingly.

• 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

• RayPlante: I've fixed all these in the pending version. Thanks for the careful reading!

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

• Per previous comments, the use of "compliment service instances" still appears in the doc instead of 'compliant'(the 'pending version' link in other responses also returns a 404)
  • RayPlante: see pending version (not the one you read)
• Sec 3.1.3 refers to "" in the last sentence, think you want ""
  • RayPlante: thanks.
• Architecture diagram still appears missing from PDF version
  • RayPlante: will fix in next release.

-- MikeFitzpatrick - 17 October 2011

-- PatrickDowler - 2011-11-21 Approved.

Data Model Working Group (Jesus Salgado, Omar Laurino)

Congratulations for the work done. I approve the document. I have some minor comments and a question for future versions.

• In the pdf version the architecture image is not shown properly for me. It could be a problem with my acrobat reader but please take a look into it.
• The example in the text:

xsi:schemaLocation="http://www.ivoa.net/xml/StandardsRegExt/v1.0 http://www.ivoa.net/xml/StandardsRegExt/v1.0"

is a typo? (the repetition of the url)

• • RayPlante: No, it's correct. The value of xsi:schemaLocation Namespace is one or more URI-URL pairs; i.e. the first URI is the XML namespace URI, the second is the URL for getting the schema document; this follows our convention that these XML Schema URIs be resolvable.

• IVOA Tehcnical Coordination -> IVOA Technical Coordination

in the references

• • RayPlante: thanks.

Now one more difficult.

• It would be nice to have a more complete example (at "An example of a Standard resource that summarizes this specification") including e.g. the interface of a protocol. In case this is too complex to be done at this step of the RFC process, present example is OK for me.

And a future possible feature:

• How do you see to include in future revisions of this specification, in the same way we do with the interface for protocols, a way to publish the utypes for datamodels?

• • RayPlante: I suppose this is possible, but with the number of utypes and detailed interrelationships, would SCOS be a better way to document this? Another question would be, do we expect to want to refer to a utype as a URI? If so, then definition of the utype via StandardsRegExt would a way to do this.

-- JesusSalgado - 19 Oct 2011

-- Approved JesusSalgado - 28 Feb 2012

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

• AndreasWicenec: The standard is mostly ok, but I think the scope should be extended to include the possibility to reference also to the schema not just to a human readable document. This would allow schema discovery as well. Could be implemented using an additional optional element called . In the same way we could also implement a link to separate complete example documents with an element .

I approve the document.

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

• Note from RayPlante: I've addressed comments from Taylor and Derriere in the pending version. If there are no more comments, this pending version is ready for upload and Exec review.

-- I approve this document. GretchenGreene - 28 February 2012

Semantics Working Group (Sebastien Derriere, Norman Gray)

A few typos noted in the document :

• In section 1, 2nd paragraph, I don't understand the sentence "... aid in the unambiguous discovery of compliment service instances". Mark Taylor points this and suggest to write complementary. Should the word not be compliant instead?
• Missing figure 1 in PDF document
• in section 3.1, in the text, a tag is written "endorsedStandard" instead of "endorsedVersion"
• in the table for endorsedVersion's attributes, last line: a versions -> a version

With these changes, the Semantics WG approves the document.

-- SebastienDerriere - 13 Oct 2011

• RayPlante: I've fixed all these in the pending version. See note about "compliant" above. Thanks for the careful reading!

VOEvent Working Group (Matthew Graham, John Swinbank)

A few comments:

• Introduction, para. 3: How are standards published in the Registry of Registries? Its web page only currently talks about registering registries with it and there seems to be no way to publish to it otherwise. Please can this be clarified.
  • RayPlante: This question is covered more appropriately in the already published RofR Note. The RofR is a compliant publishing registry to which we can add arbitrary documents; no changes to the RofR nor to the registries and applications that use are needed.
• Section 2.2: It appears that the same keys can be registered as both part of a vstd:Standard and in a vstd:StandardKeyEnumeration. What is the best practice and which would take precedence if this happened?
  • RayPlante: Added Note box recommending use of vstd:Standard or vstd:ServiceStandard to describe keys that are defined in an IVOA document.
• Section 2.3, para. 4 (and sec. 3.2, vstd:StandardKey Metadata Elements): There should be explicit mention that a key name cannot contain a '#'
  • RayPlante: added (in 2 places)
• Section 3.1.1, vstd:EndorsedVersion Attributes: Additional allowed values that would be useful would be "Internal Draft" and "Note"
  • RayPlante: added "iwd" and "note" as allowed values (see pending version).
• Section 3.1.2: Can an example for a ServiceStandard resource be given?
  • RayPlante: Added as App. B.

A few typos noted in the document:

• Introduction, para. 2: "conform to particular standard" should be "conform to a particular standard"
• Section 2.2, vstd:StandardKeyEnumeration: "related set controlled names" should be "related set of controlled names"
• Section 2.3, para. 1: "defining metadata to" should be "defining metadata is to"
• Section 2.3, Note: "expected that the only the" should be "expected that only the"
  • RayPlante: fixed (see pending version); thanks!

With these changes, the VOEvent WG approves the document.

-- MatthewGraham - 21 Nov 2011

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)