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/20110316/PR-StandardsRegExt-1.0-20110323.html.
RFC Review period: 14 Apr 2011 -- 14 May 2011.
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
This document looks mostly good, and the StandardKeyEnumeration element in particular is a useful tool. I have a few comments and corrections:
- 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?
- 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.
- 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.
- 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.
- 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..."
- 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