IVOA Document Standards RFC (Version 1.2)This document will act as RFC centre for the IVOA Document Standards 1.2 Proposed Recommendation. Review period: 12 May 2009 to 11 June 2009 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 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. Discussion about any of the comments or responses should be conducted on the Standing Committee on Standards & Processes mailing list, stdproc@ivoa.net. For reference, here is a link to the first RFC (Version 1.1) The comments (M. Deimletner, M. Taylor) posted on the page open for comments on V1.2 WD are copied below.CommentsMinimal implementation rulesI'm not sure if this is one of these "not again" topics, but I'd really like so see something on the implementation side. Let me dream for a moment: What if the document said something like "A PR describing protocols, formats or similar computer processible artefacts can only become REC if (a) at least two independent implementations [fantasy: one of them in a C-linkable language; this would almost immediately allow bindings for basically all major languages] are available and (b) a validation suite is provided that allows implementors to verify the conformity of their implementation [for what it's worth]". As a matter of fact, I think the validation suite would be worth more than all words and probably even formal specifications, since the behaviour defined by it is behaviour clients can rely on. Now, I admit that if something like this were to become part of the standards process, more diligence is needed as to the wording, and certain details would have to be worked out (if I had my way, I'd require the implementations to be published under a DFSG-free licence, for starters). But I'm convinced the VO would be more fun to work and more robust with if rules like these were adopted. -- MarkusDemleitner - 17 Feb 2009Me tooI welcome the introduction since v1.0 of a reference to validation tools in the WD->PR promotion rules (section 2.1). However, the language is pretty pusillanimous:"Preferably, the WG should be able to demonstrate two interoperable implementations of each feature, and validation tools should be available. If the chair of the WG believes that broader review is critical, the chair may advance the document to Proposed Recommendation even without adequate implementation experience. In this case the document status section should indicate why the chair promoted the document directly to PR."I have two issues with this text.
VersioningThe document now states that there is an integer increment in the version number in the case where subsequent versions are not backward compatible. However, the matter of how this impacts (web) service standards still remains open and needs addressing. To recap, any new version/revision of a (web) service standard will have to have an integer increment since it will be incompatible with previous versions: service request/response messages use namespaces to identify the version, e.g.<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope"> <soapenv:Header> <soapenv:Body> <PushToVoSpace xmlns="http://www.net.ivoa/xml/VOSpaceContract-v1.0"> ...The namespace on the message body - http://www.net.ivoa/xml/VOSpaceContract-v1.0 - indicates that this is a message to a VOSpace-1.0 compliant service. The same message to a VOSpace 1.1 service would utilise the namespace http://www.net.ivoa/xml/VOSpaceContract-v1.1 instead. A VOSpace-1.0 client cannot be used with a VOSpace-1.1 service and vice versa. So by the new rule VOSpace-1.1 should actually be VOSpace-2.0. The same argument applies, however, to minor changes, e.g. VOSpace-1.13 to VOSpace-1.14. This brings up another point - how should associated schema, WSDLs, etc., in fact anything with a namespace, be versioned? With the version number of the associated document? For example, the change from v1.13 to v1.14 of a standard just reflects a format change in the WSDL document but this is "new incompatible" version. Should all service standards just employ integer versioning? I also think that the language about supplementary resources needs to be strengthened. For a web service, the WSDL and any accompanying schema formally define the service interface and contract - these are really not supplemental in any sense but the machine-readable equivalent of the human-readable specification that the document represents. Additional implementations in these contexts will employ different namespaces and so will be not be interoperable. I do not think it is necessary to include the full text of such accompaniments in the human spec but they must be referenced and authoritative versions deposited with the IVOA Document Coordinator. We already have locations for such things: http://www.ivoa.net/xml, http://www.ivoa.net/wsdl and http://www.ivoa.net/rdf and these should be referenced in this document. -- MatthewGraham - 12 May 2009 Sect 1.1: It would be useful to include the boilerplate in this section. While it may vary slightly in practice, I imagine most folk will simply lift this from another random standard, rather than being creative. Sect 1.2: I don't think it intends to, but the example progression of file names appears to suggest that a document appears solely as a PDF when it becomes a REC, and the HTML disappears. Sect 1.5: In the case of WSDL files, schemas and I think most RDF files, the `supplementary resources' are not really supplementary, but as normative as any document text (as others have said). It might even be the case that all of these resources are normative. The issue, then, is whether anything has to be said about their normativity, and if so, where. I'd think that it would be sufficient to avoid making any statement about the normativity of other resources, but require the document to list the resources in question (perhaps in a special section?) and state whether they're normative or not. Or is this going into too much detail? On that topic, it might be worth while requiring that the document is explicit about which sections are normative and which are informative. The Vocabularies document has a section in the preamble about this. Section 2.1: I'm another one who would prefer a pair of implementations to be mandatory, and probably prefer that they were independent, too. It'd probably be necessary to have some discretion, to handle the cases where it's not obvious what counts as an 'implementation'. For example, I've taken it that the Vocabularies document has four implementations, in the four vocabularies, but (a) one could take a different view of that, and (b) all four were produced by the document authors. -- NormanGray - 24 May 2009 | ||||||||
Added: | ||||||||
> > | After reading the draft I have two comments.... First, I think it would be helpful to standardize the location of these Wiki discussions. These can be relevant even after the standard is finalized. I often find it difficult to find these discussions and occasionally fail to comment simply because by the time I work my way through the E-mail or web links to locate the RFC page I been distracted by some other task. We want to make commenting as easy as possible. More significantly, I would like to put in my voice in support of the view that building a validation service should be a mandatory element of the standards development. Personally I think that having validators will greatly speed up the adoption of the protocols. I think there could be a significant degree of flexibility here just as there is for the development of the qualifying implementations. In a some cases (e.g., the current standard) validation may be inappropriate and in general I think it should be the purview of the working group to decide what level of validation is good enough (subject to review by the IVOA more generally when the document as the document goes through the promotion process). While I believe validators would actually speed adoption of standards, some fear that this requirement would slow things down and there is particular interest that TAP not be delayed. If TAP is the real issue here then perhaps the requirement for validators could be delayed for six months or perhaps generally standards that are in an RFC before the standard process is updated could be grandfathered against new requirements. Then we'd have additional incentive to get TAP done quickly! -- TomMcGlynn 11 June 2009 | |||||||
Comments from the TCG during the normal RFC period (starting 12/05/2009) | ||||||||
Added: | ||||||||
> > | ||||||||
Applications (Tom McGlynn, Mark Taylor) | ||||||||
Added: | ||||||||
> > | There has been no official response from the Working group with regard to any of the issues raised, notably with respect to whether validaters should be mandatory. This aspect of the standard will have a major impact on the quality of the tools and services provided by the VO. [TAM] | |||||||
Data Access Layer (Keith Noddle, Jesus Salgado)Data Model (Mireille Louys, AnitaRichards)Grid&Web Sevices (Matthew Graham, Paul Harrison)Registry (Ray Plante, Aurelien Stebe)Semantics (Sebastien Derriere, Norman Gray)VOEvent (Rob Seaman, Alasdair Allan)VO Query Language (Pedro Osuna, Yuji Shirasaki)VOTable (François Ochsenbein)Standard and Processes (Francoise Genova)Astro RG (Masatoshi Ohishi)Data Curation & Preservation (Bob Hanisch)I approve.Theory (Herve Wozniak, Claudio Gheller)Approved.TCG (ChristopheArviset, Severin Gaudet)I approve the document. |