VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
When the CADC implemented version 2.1 of the VOSpace service, the python client that was built on the 2.0 specification was not changed. The fact that no errors or disruption was seen by users is evidence of the backwards compatibility between version 2.1 and version 2.0. -- BrianMajor - 2018-05-16 Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
We validate VOSPace which is a sophisticated and well written standard.
We would like to make a (non blocking) suggestion. Maybe between adoption and REC publication or for next version. - A model diagram like the one in fig 2 with all the classes, not only "node". Relationships should be shown but no need to do a full UML diagram. - A couple of diagrams showing where Web service operations occur (VOSPACE to client. Client to VOSPACE. Inside a VOSPACE. From: VOspace to another One etc...) Typos/minor suggestions
-- FrancoisBonnarel - 2018-05-25 -- MarcoMolinaro - 2018-05-25 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )I did not see much overlap for this specification with the work covered by the Semantics WG. Document approved. A minor comment : "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . -- MireilleLouys - 2018-05-16 Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
When the CADC implemented version 2.1 of the VOSpace service, the python client that was built on the 2.0 specification was not changed. The fact that no errors or disruption was seen by users is evidence of the backwards compatibility between version 2.1 and version 2.0. -- BrianMajor - 2018-05-16 Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )I did not see much overlap for this specification with the work covered by the Semantics WG. Document approved. A minor comment : "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . -- MireilleLouys - 2018-05-16 Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This PR has taken into account all comments up until April 16, 2018.
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
When the CADC implemented version 2.1 of the VOSpace service, the python client that was built on the 2.0 specification was not changed. The fact that no errors or disruption was seen by users is evidence of the backwards compatibility between version 2.1 and version 2.0. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | -- BrianMajor - 2018-05-16 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )I did not see much overlap for this specification with the work covered by the Semantics WG. Document approved. A minor comment : "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . -- MireilleLouys - 2018-05-16 Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
| ||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||
< < | Please note your implementation or validator in this section. | |||||||||||||||||||||||||||||||||||||
> > | The CADC has two VOSpace client implementations, one written in java (mostly used for testing) and one written in python. The python client is the CADC production client that is distributed to users and can be seen/installed here: CADC VOSpace client When the CADC implemented version 2.1 of the VOSpace service, the python client that was built on the 2.0 specification was not changed. The fact that no errors or disruption was seen by users is evidence of the backwards compatibility between version 2.1 and version 2.0. | |||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||
< < | ||||||||||||||||||||||||||||||||||||||
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )I did not see much overlap for this specification with the work covered by the Semantics WG. Document approved. A minor comment : "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . -- MireilleLouys - 2018-05-16 Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi ) | ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < | I did not see much overlap for this specification with the work covered by the Semantics WG. | |||||||||||||||||||||||||
> > | I did not see much overlap for this specification with the work covered by the Semantics WG. | |||||||||||||||||||||||||
Document approved.
A minor comment : | ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < | "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . | |||||||||||||||||||||||||
> > | "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . | |||||||||||||||||||||||||
-- MireilleLouys - 2018-05-16
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
| ||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | I did not see much overlap for this specification with the work covered by the Semantics WG.
Document approved. A minor comment : "3.2.3 Property descriptions" subsubsection mentions the use of UCD Unified Content Descriptor very popular inside the VO framework. The reference to the last version of the specification (http://www.ivoa.net/documents/UCD1+/) could be added in the References section . -- MireilleLouys - 2018-05-16 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| ||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. -- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | ==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
-- BrianMajor - 2018-05-02
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. -- BrianMajor - 2018-05-02
page 8 (line 199 in tex) In
(line 518 in tex) \label{subsubsection:ui display
page 42 (line 1428 in tex) If the node path of the
page 54 (line 1960 in text) A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the
page 71 (line 2875 in tex) HTTP POST to
page 78 (line 3283 in tex) REQUEST=redirect and
page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... -- DaveMorris - 2018-05-02 ==> Thanks. All these edits have been made to the document linked on this page. -- BrianMajor - 2018-05-02
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
==> Thanks for your detailed review Pierre. I have addressed some of your points above, but not all. I've left the ones that would require significant enough changes as to warrant another review.
-- BrianMajor - 2018-05-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 8 (line 199 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ==> I agree Dave. As discussed in Santiago (Oct 2017), there is not a use case for these extra VOSpace capabilities. Let's ensure that section is updated in the next version. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | In | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | (line 518 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | -- BrianMajor - 2018-05-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | \label{subsubsection:ui display | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 42 (line 1428 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 8 (line 199 in tex) In | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | If the node path of the | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 54 (line 1960 in text) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | (line 518 in tex) \label{subsubsection:ui display | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | A Node containing the Node | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 58 and 66 (lines 2222 and 2642 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 42 (line 1428 in tex) If the node path of the | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | create a new Node using the | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 71 (line 2875 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 54 (line 1960 in text) A Node containing the Node | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | HTTP POST to http://rest- | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 78 (line 3283 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 58 and 66 (lines 2222 and 2642 in tex) create a new Node using the | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | REQUEST=redirect and | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 82 (line 3519 in tex) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 71 (line 2875 in tex) HTTP POST to http://rest- | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | This is thrown with the | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | page 99 (line 3649) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 78 (line 3283 in tex) REQUEST=redirect and | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Deleted: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | vospace/core#publisher .... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | page 82 (line 3519 in tex) This is thrown with the
page 99 (line 3649) vospace/core#publisher .... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-- DaveMorris - 2018-05-02 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | ==> Thanks. All these edits have been made to the document linked on this page.
-- BrianMajor - 2018-05-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions : I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
page 8 (line 199 in tex)
In
(line 518 in tex)
\label{subsubsection:ui display
page 42 (line 1428 in tex)
If the node path of the
page 54 (line 1960 in text)
A Node containing the Node
page 58 and 66 (lines 2222 and 2642 in tex)
create a new Node using the
page 71 (line 2875 in tex)
HTTP POST to
page 78 (line 3283 in tex)
REQUEST=redirect and
page 82 (line 3519 in tex)
This is thrown with the
page 99 (line 3649)
vospace/core#publisher .... -- DaveMorris - 2018-05-02 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _Ada Nebot, Dave Morris )Probably too late for this version, but for future reference : In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions :
| |||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | |||||||||||||||||||||||||||||||||||||||||||
I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting.
The earlier text in version-1.12 refers to standard URIs for other types of VO services :
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||||||||||||||||||||
> > | There is an (edge) use case for allowing services to include Capability elements for the VOSpace service itself. This could potentially allow a VOSpace client to bootstrap itself given just the XML for the node. | ||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | There is an (edge) use case for allowing services to include Capability elements for the VOSpace service itself. This could potentially allow a VOSpace client to bootstrap itself given just the XML for the node. | ||||||||||||||||||||||||||||||||||||||||||
However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. | |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different | ||||||||||||||||||||||||||||||||||||||||||
> > | As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. | ||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | set of Capability URIs replicating the standard VOSI Capability URIs for each service type. | ||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < | Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard | ||||||||||||||||||||||||||||||||||||||||||
> > | Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. | ||||||||||||||||||||||||||||||||||||||||||
Deleted: | |||||||||||||||||||||||||||||||||||||||||||
< < | VOSI Capability URIs for each service type. | ||||||||||||||||||||||||||||||||||||||||||
So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12.
-- DaveMorris - 2018-05-01
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||||||||||||||||||||
< < |
| ||||||||||||||||||||||||||||||||||||||||||
> > |
| ||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway ) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Changed: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
< < | Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick ) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > | Time Domain Interest Group ( _Ada Nebot, Dave Morris ) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
Probably too late for this version, but for future reference :
In response to questions from MarkusDemleitner about the standard capability URIs in section 3.3.5. The standard capability URIs for different version of the VOSpace service were added to section 3.3.5 between the following versions :
I can't find anything on the mailing list discussing these changes, so I assume these were proposed and discussed at a meeting. The earlier text in version-1.12 refers to standard URIs for other types of VO services :
There is an (edge) use case for allowing services to include Capability elements for the VOSpace service itself. This could potentially allow a VOSpace client to bootstrap itself given just the XML for the node. However, all of these use cases work perfectly well using the standard VOSI URIs for these Capabilities. As one of the original advocates for the Capabilities functionality, I can see no reason for declaring a different set of Capability URIs replicating the standard VOSI Capability URIs for each service type. Non IVOA services or capabilities will need their own URIs, but standard IVOA services can use the standard VOSI Capability URIs for each service type. So at some point, I would suggest we revert the text in section 3.3.5 to something like the original text in section 2.3.5 of version-1.12. -- DaveMorris - 2018-05-01 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Added: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> > |
TCG Vote : 2018-04-23 - 2018-05-04If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. Suggestions, questions and typos:
| ||||||||
Changed: | ||||||||
< < | Suggestions for a future release 2.2 : | |||||||
> > | Suggestions for a future release 2.2 : | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- PierreFernique - 2018-04-24
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until April 16, 2018.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson ) | ||||||||
Added: | ||||||||
> > | First of all, I have to thanks the editors. This new version of the document has been improved compared to the 2.1 first version: more examples, more definitions and vocabulary explanations - clearly easier to read and to understand. VOSpace is a protocol quite heavy to code and presently we have very few working implementations even with the VOSPace predecessors (clients and servers). I hope that this new document/version will facilitate the life of the future implementors. Suggestions, questions and typos:
| |||||||
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: | ||||||||
Changed: | ||||||||
< < | This PR has taken into account all comments up until September 24, 2017. | |||||||
> > | This PR has taken into account all comments up until April 16, 2018. | |||||||
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until September 24, 2017.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
This PR has taken into account all comments up until September 24, 2017.
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
(3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13.
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until September 24, 2017.Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 | ||||||||
Added: | ||||||||
> > |
| |||||||
(2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note?
=> Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 | ||||||||
Added: | ||||||||
> > |
| |||||||
(3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13.
=> I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. | ||||||||
Changed: | ||||||||
< < | The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here: | |||||||
> > | The latest VOSpace 2.1 Proposed Recommendation (the second PR of this RFC) can be viewed here: This PR has taken into account all comments up until September 24, 2017. | |||||||
Deleted: | ||||||||
< < | ||||||||
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. => I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. => I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). | ||||||||
Changed: | ||||||||
< < | Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. | |||||||
> > | => Thanks for the standards record in volute, I will indeed update it. See (2) for more comments. | |||||||
I don't think there's a reference to ivo://ivoa.net/vospace/v2.0
-- BrianMajor - 2017-09-21 (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document. -- BrianMajor - 2017-09-21 (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. => Done. -- BrianMajor - 2017-09-21 (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard. -- BrianMajor - 2017-09-21 (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? => That text seems outdated. I've remove that list. -- BrianMajor - 2017-09-21 (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? => Also outdated. Removed. (And yes to the registry extension work) -- BrianMajor - 2017-09-21 (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. => This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
| ||||||||
Deleted: | ||||||||
< < | ||||||||
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. => I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable | ||||||||
Changed: | ||||||||
< < | You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 | |||||||
> > | => You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 | |||||||
Section 3.1
It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. | ||||||||
Changed: | ||||||||
< < | Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 | |||||||
> > | => Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 | |||||||
Thrown Exception
It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. | ||||||||
Changed: | ||||||||
< < | I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12 | |||||||
> > | => I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12 | |||||||
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). | ||||||||
Added: | ||||||||
> > | Thanks for the standards record in volute, I will indeed update it. See (2) for more comments.
I don't think there's a reference to ivo://ivoa.net/vospace/v2.0 -- BrianMajor - 2017-09-21 | |||||||
(2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. | ||||||||
Added: | ||||||||
> > | => Yes, I think we can make that change since there is no operational discovery in place. So, the standardIDs are now:
-- BrianMajor - 2017-09-21 | |||||||
(3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. | ||||||||
Added: | ||||||||
> > | => I've fixed the English, but I'm reluctant to put in more details in this introductory section of the document.
-- BrianMajor - 2017-09-21 | |||||||
(4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. | ||||||||
Added: | ||||||||
> > | => Done.
-- BrianMajor - 2017-09-21 | |||||||
(5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). | ||||||||
Added: | ||||||||
> > | => There will be the three StandardRegExt records. So, I guess we need to create an extension that will allow descriptions of the keys. I am happy to do that but hope it will not hold up this standard.
-- BrianMajor - 2017-09-21 | |||||||
(6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? | ||||||||
Added: | ||||||||
> > | => That text seems outdated. I've remove that list.
-- BrianMajor - 2017-09-21 | |||||||
(7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? | ||||||||
Added: | ||||||||
> > | => Also outdated. Removed. (And yes to the registry extension work)
-- BrianMajor - 2017-09-21 | |||||||
(8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. | ||||||||
Added: | ||||||||
> > | => This was wrong. The idea is that "(job-id)/results/transferDetails" can be appended to the resolved transfer URL to obtain the results. Thanks for catching that, it's been fixed. -- BrianMajor - 2017-09-21 | |||||||
(9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record.
=> This has been done. -- BrianMajor - 2017-09-20 (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
| ||||||||
Added: | ||||||||
> > |
| |||||||
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. => I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. => Done. -- BrianMajor - 2017-09-19 (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19
(7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? => Removed. -- BrianMajor - 2017-09-19 (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. => "UWS" has been removed. -- BrianMajor - 2017-09-19 (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. => Okay, thanks. -- BrianMajor - 2017-09-19 -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. | ||||||||
Added: | ||||||||
> > | => Yes. I had missed adding the CADC VOSpace compliance tool to the top of this page (there now), but it is a validator for 2.0 services. It does pass on our 2.1 implementation which is assuring for backwards compliance, but it does not validate new 2.1 functionality. This is something that can be discussed more. -- BrianMajor - 2017-09-20 | |||||||
(1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2).
(2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. | ||||||||
Added: | ||||||||
> > | => This has been done. -- BrianMajor - 2017-09-20 | |||||||
(10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. | ||||||||
Added: | ||||||||
> > | => I don't understand that either. I've asked the original authors in the mailing list for an explanation but have not received a response. email thread -- BrianMajor - 2017-09-20 | |||||||
-- MarkusDemleitner - 2017-06-12
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. | ||||||||
Added: | ||||||||
> > | => I don't think there's a use case involving comparing VOS Identifiers. If you can live it, I'd rather not tackle these references to encoding in this minor version. -- BrianMajor - 2017-09-19 | |||||||
(4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. | ||||||||
Added: | ||||||||
> > | => Done. -- BrianMajor - 2017-09-19 | |||||||
(5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? | ||||||||
Added: | ||||||||
> > | => Good point. I've removed that paragraph as it was really only confusing matters. -- BrianMajor - 2017-09-19 | |||||||
(6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. | ||||||||
Changed: | ||||||||
< < | (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. | |||||||
> > | => Editor error. This text was meant for the 'optional' flag. Thanks. -- BrianMajor - 2017-09-19 | |||||||
Added: | ||||||||
> > | (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. => I think that would be a good improvement. -- BrianMajor - 2017-09-19 | |||||||
(8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. | ||||||||
Added: | ||||||||
> > | => I think you're right so I've changed it to application/octet-stream. -- BrianMajor - 2017-09-19 | |||||||
(9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? | ||||||||
Added: | ||||||||
> > | => Removed. -- BrianMajor - 2017-09-19 | |||||||
(10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? | ||||||||
Added: | ||||||||
> > | => Okay, good idea. I've made changes to that section that are a blend of your suggestions and the original content. Hopefully it sits better with you now. -- BrianMajor - 2017-09-19 | |||||||
(11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. | ||||||||
Added: | ||||||||
> > | => "UWS" has been removed. -- BrianMajor - 2017-09-19 | |||||||
(12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). | ||||||||
Added: | ||||||||
> > | => Thanks, now cleaned up. -- BrianMajor - 2017-09-19 | |||||||
(13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. | ||||||||
Added: | ||||||||
> > | => Okay, thanks. -- BrianMajor - 2017-09-19 | |||||||
-- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. | ||||||||
Added: | ||||||||
> > | => I don't see the referencing failures, but I've taken out those lines anyhow. -- BrianMajor - 2017-09-19 | |||||||
(2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? | ||||||||
Added: | ||||||||
> > | => Well, yes, this was actually the original use case for the XML schema versioning note and I had forgotten to bring in the change. Thanks for noticing. The XSD namespace is now 2.0 and there is a version attribute in the <transfer> root element. This is the only element that has XSD changes (introduction of security method and transfer param). The search and find features (which I think you are referring) were never actually in the XSD. (That's why they were dropped from 2.1.) -- BrianMajor - 2017-09-19 | |||||||
(3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13.
(4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable | ||||||||
Changed: | ||||||||
< < | You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 | |||||||
> > | You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 | |||||||
Deleted: | ||||||||
< < | ||||||||
Section 3.1
It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. | ||||||||
Changed: | ||||||||
< < | Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 | |||||||
> > | Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 | |||||||
Thrown Exception
It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. | ||||||||
Changed: | ||||||||
< < | I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12 | |||||||
> > | I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12 | |||||||
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )(0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. -- MarkusDemleitner - 2017-06-12 Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. -- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable | ||||||||
Added: | ||||||||
> > | You may be right, there is a lot of information in this section, but I am hesitant to make such a significant change to the document at this point. I have reworded the sentence to make the pronoun match the plurality. -- BrianMajor - 2017-09-12 | |||||||
Section 3.1
It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. | ||||||||
Added: | ||||||||
> > | Section 1.2 hints at 'interpreting data' with the mention of views, but goes no further. Again, I don't wish to make changes to these sections if not necessary. -- BrianMajor - 2017-09-12 | |||||||
Thrown Exception
It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. | ||||||||
Added: | ||||||||
> > | I disagree. The exceptions a service can throw are a part of its API so must be documented. Clients and services are likely to be implemented by different groups. -- BrianMajor - 2017-09-12 | |||||||
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower ) | ||||||||
Changed: | ||||||||
< < | (0) I'd be a lot more relaxed if there were some sort of validator, or | |||||||
> > | (0) I'd be a lot more relaxed if there were some sort of validator, or at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. | |||||||
Deleted: | ||||||||
< < | at least the beginnings of one. Is there really no plan for one? A spec this complex (there are 164 lines in this spec with MUST or SHALL alone, and the 65 items in Appendix B are already a steep programme in themselves...) probably has lots of ugly corner cases or subtle contradictions, and if someone said "I've went through the spec and produced first validator code, and while doing that I've not ran into major issues", that'd be reassuring. | |||||||
Changed: | ||||||||
< < | (1) For proper Registry semantics, you need to provide a | |||||||
> > | (1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). | |||||||
Deleted: | ||||||||
< < | StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). | |||||||
Changed: | ||||||||
< < | (2) I am really unhappy with the standardID (sect. 2, p. 10). | |||||||
> > | (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. | |||||||
Deleted: | ||||||||
< < | ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. | |||||||
Changed: | ||||||||
< < | (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with | |||||||
> > | (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. | |||||||
Deleted: | ||||||||
< < | registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. | |||||||
Changed: | ||||||||
< < | (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it | |||||||
> > | (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. | |||||||
Deleted: | ||||||||
< < | doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. | |||||||
Changed: | ||||||||
< < | (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO | |||||||
> > | (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). | |||||||
Deleted: | ||||||||
< < | registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). | |||||||
Changed: | ||||||||
< < | (6) Sect. 3.3.5, "Other standard service interfaces will also be | |||||||
> > | (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? | |||||||
Deleted: | ||||||||
< < | registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? | |||||||
Changed: | ||||||||
< < | (7) p. 24, "However, at the time of writing, the schema for registering | |||||||
> > | (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? | |||||||
Deleted: | ||||||||
< < | ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? | |||||||
Changed: | ||||||||
< < | (8) p. 36, the URI | |||||||
> > | (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. | |||||||
Deleted: | ||||||||
< < | ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. | |||||||
Changed: | ||||||||
< < | (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think | |||||||
> > | (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. | |||||||
Deleted: | ||||||||
< < | that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. | |||||||
Changed: | ||||||||
< < | (10) I can't work out the relationship of the capability URIs in sect. | |||||||
> > | (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. | |||||||
Deleted: | ||||||||
< < | 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. | |||||||
-- MarkusDemleitner - 2017-06-12
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from Markus Demleitner | ||||||||
Changed: | ||||||||
< < | (1) The compliance matrix has links to findnodes and searches sections, | |||||||
> > | (1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. | |||||||
Deleted: | ||||||||
< < | which are commented out; hence the referencing fails. I think you should just remove the matrix lines. | |||||||
Changed: | ||||||||
< < | (2) You're changing the target namespace of your schema; from what I can | |||||||
> > | (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? | |||||||
Deleted: | ||||||||
< < | see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? | |||||||
Changed: | ||||||||
< < | (3) I get a bit nervous about "uri: the vos:// identifier for the node, | |||||||
> > | (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. | |||||||
Deleted: | ||||||||
< < | URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. | |||||||
Changed: | ||||||||
< < | (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a | |||||||
> > | (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. | |||||||
Deleted: | ||||||||
< < | distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. | |||||||
Changed: | ||||||||
< < | (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 | |||||||
> > | (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? | |||||||
Deleted: | ||||||||
< < | client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? | |||||||
Changed: | ||||||||
< < | (6) p. 22, "uri: an optional boolean flag to indicate that the View | |||||||
> > | (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. | |||||||
Deleted: | ||||||||
< < | preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. | |||||||
Changed: | ||||||||
< < | (7) Perhaps for the next version, I think having a single section on | |||||||
> > | (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. | |||||||
Deleted: | ||||||||
< < | identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. | |||||||
Changed: | ||||||||
< < | (8) p. 26 "to the application/binary MIME type." After consulting my | |||||||
> > | (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. | |||||||
Deleted: | ||||||||
< < | /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. | |||||||
Changed: | ||||||||
< < | (9) p. 26 "the available views (the server) thinks is the most" -- why | |||||||
> > | (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? | |||||||
Deleted: | ||||||||
< < | the parentheses? | |||||||
Changed: | ||||||||
< < | (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in | |||||||
> > | (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? | |||||||
Deleted: | ||||||||
< < | effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? | |||||||
Changed: | ||||||||
< < | (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- | |||||||
> > | (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. | |||||||
Deleted: | ||||||||
< < | is there such a thing? I'd say the "UWS" needs to go from that statement. | |||||||
Changed: | ||||||||
< < | (12) In several places, there still are hardcoded section references in | |||||||
> > | (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). | |||||||
Deleted: | ||||||||
< < | the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). | |||||||
Changed: | ||||||||
< < | (13) With my hat as ivoatex author on, I remark that my recommendation | |||||||
> > | (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. | |||||||
Deleted: | ||||||||
< < | is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. | |||||||
-- MarkusDemleitner - 2017-06-12
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue.
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower ) | ||||||||
Added: | ||||||||
> > | (0) I'd be a lot more relaxed if there were some sort of validator, or
at least the beginnings of one. Is there really no plan for one? A
spec this complex (there are 164 lines in this spec with MUST or SHALL
alone, and the 65 items in Appendix B are already a steep programme in
themselves...) probably has lots of ugly corner cases or subtle
contradictions, and if someone said "I've went through the spec and
produced first validator code, and while doing that I've not ran into
major issues", that'd be reassuring.
(1) For proper Registry semantics, you need to provide a StandardsRegExt record ivo://ivoa.net/vospace/core, which is a bit non-standard in that it doesn't really match a standard at all (see also (2)), and another StandardsRegExt record ivo://ivoa.net/vospace/v2.0 (which is also suboptimal in that it, for instance, contains a minor version number). Under the assumption that we cannot change any of the existing URIs pointing to these two records without breaking the protocol, I've drafted these two records in addition to the main standard record in volute. If these reflect your intentions, please fix the dates marked with UPDATEME on acceptance of the standard and then mail them (or their URLs) to the RofR maintainers. Of course, further review and changes would be highly appreciated. On the other hand, if they can be changed, it'd be great if the changable ones would point to the record mentioned in (2). (2) I am really unhappy with the standardID (sect. 2, p. 10). ivo://ivoa.net/std/VOSpace/v2.1. For one, with such a versioning, you'd probably break your protocol (or at least the usual discovery patterns) on each minor revision. Since this URI is new anyway, could we still change it to something in the style of Identifiers 2.0, i.e., ivo://ivoa.net/std/VOSpace? I've put in a StandardsRegExt record for that IVOID into volute. This is also where new terms should be created if at all possible, and hence I've put the new synctrans-2.0 there. (3) Sect 2.1, "Resolve HTTP service endpoint of VOSpace service with registry" -- there's a "the" missing here, but even with it I think you'd do your readers a favour if you're a bit more explicit, e.g., "The HTTP endpoint is a vs:ParamHTTP-typed interface with @std set to True that is a child of a capability with a standardID as specified above." Or so. (4) Sect 3.1, "the type is specified by the xs:type attribute" -- it doesn't matter much in this context, but in Registry we urge people to use "canonical" prefixes. The really only does matter when you have prefixed values in attributes, which probably is not the case here. Still, if you don't mind much, I'd prefer to have xsi: as the implied prefix for schema-instance in your examples. (5) Sect. 3.2.2, p. 15 says "Ideally, these [properties] should be IVO registry URIs that point to a description registered in the IVO registry..." I think if you say that you'll also have to say how such a "registration" is supposed to work (StandardRegExt records?). Since I don't know enough about how this mechanism is supposed to work, I can't really suggest some text. I'm not even sure you shouldn't be using plain RDF vocabularies (as pioneered by Datalink) rather than the Registry here in the first place. How about retracting the entire statement about registered property names and waiting until people have use cases? This even becomes worse with 3.2.3; there currently is no way to provide such a property description in the Registry. If this stays in, we should draft a registry extension that allows these tricks now. I'm happy to help, perferably when someone actually has some property to register (this could be part of a VOSpaceRegExt that might live outside of VOSpace proper, but then you need to reference it in 3.2.3). (6) Sect. 3.3.5, "Other standard service interfaces will also be registered..." -- I don't think this piece helps a lot, but I can see many ways in which it can be confusing ("will? do I have to do it? when? how?"). I think I'd prefer if it and the enumeration were to go. Or did I simply not get what you say here? (7) p. 24, "However, at the time of writing, the schema for registering ViewDescriptions in the IVO registry has not been finalized." -- I'm somewhat embarrassed to see such language in a version 2.1 (rather than 1.0 or even 2.0). If you really don't want to include the registry extension for 2.1, can we just get together right after 2.1 to do the registry extension (or whatever else)? (8) p. 36, the URI ivo://ivoa.net/std/VOSpace/v2.0#/transfers/(job-id)/results/transferDetails -- by the book, this should resolve to a StandardsRegExt StandardKey, which is of course impossible given that there's a variable (right?) jobID in there. How should clients even use that standardID? Anyway, there's no way this can be represented in StandardsRegExt, so it shouldn't be in the standard in this form, and hence it's also not in the records I've prepared. To help working out a solution, I'd first need to understand how this is intended to be used. (9) p. 37 has ivo://ivoa.net/std/VOSpace?synctrans-2.1.-- I don't think that is actually what you want. As far as I can work out, this should refer to a StandardsRegExt key, and thus it should have a hash mark, i.e., ivo://ivoa.net/std/VOSpace#synctrans-2.1 (the question mark signifies a query string, i.e., something that the resource at the URI would somehow respond to). This latter term is already present in the draft StandardsRegExt record. (10) I can't work out the relationship of the capability URIs in sect. 3.3.5 (in ivo://ivoa.net/std/VOSpace/core) and those in sect. 4 (which live in ivo://ivoa.net/std/VOSpace/v2.0). Which are the ones intended to go into capabilitiy/@standardID? What's supposed to happen with the other ones? For now, I've assumed the ones in core were intended for the SOAP bindings and can just go, so they're not in the proposed records. -- MarkusDemleitner - 2017-06-12 | |||||||
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Issue: v2.1 Compliance - Obey request=redirect parameter
Please note your implementation or validator in this section. | ||||||||
Added: | ||||||||
> > | ||||||||
Comments from Pierre FerniqueImplementation references
| ||||||||
Added: | ||||||||
> > |
Comments from Markus Demleitner(1) The compliance matrix has links to findnodes and searches sections, which are commented out; hence the referencing fails. I think you should just remove the matrix lines. (2) You're changing the target namespace of your schema; from what I can see in the spec, this should break 2.0 clients, as they will not find their elements any more. Are you sure yours isn't a classic case for the XML schema versioning note? (3) I get a bit nervous about "uri: the vos:// identifier for the node, URI-encoded according to RFC3986 (Berners-Lee et al., 2005)." (p. 12) For one, I'm not sure if this is the right place to say anything about encoding, but more importantly: Are these URIs supposed to be comparable? If so, you should somewhere define how they're intended to be compared (e.g., authorities and schemes in general are case-insensitive -- are they here? What about normalising percent-encoded values?). Similarly for nodes and target, p. 13. (4) "URI or URL" (e.g., sect. 3.2, p. 14): RFC3986 discourages a distinction between URI, URL, and URN, so I'd suggest to just write "URI" in these instances. (5) The example in 3.3.5, "One use case for this would be a VOSpace 2.1 client talking to a service that implements both VOSpace 2.0 and VOSpace 2.1, where the client is acting on behalf of a third party agent that only understands VOSpace 2.0...", isn't quite convincing to me -- when you just change the minor version, shouldn't the 2.0 side be interoperable with any 2.1 side? What purpose does it then serve to discover a 2.0 service? (6) p. 22, "uri: an optional boolean flag to indicate that the View preserves..." -- are you sure this is "uri"? If so, I think a few words on why you chose this name (it is a bit odd for a boolean flag, no?) was chosen might be helpful. (7) Perhaps for the next version, I think having a single section on identifier rules that's then referenced from sections like 3.2.2, 3.3.2, 3.4.2 (just highlighting differences as necessary) will reduce repetition and make the document more readable. (8) p. 26 "to the application/binary MIME type." After consulting my /etc/mime.types I don't think application/binary is defined. I think you mean application/octet-stream. I mention in passing that these guys aren't actually called MIME types but "media types". But since nobody calls them that I'll shut up about that particular point. (9) p. 26 "the available views (the server) thinks is the most" -- why the parentheses? (10) I'm a bit split on 3.5.4 -- on the one hand, this offloads what in effect is part of the spec to a wiki page, which I'd usually like to avoid, and the separation of concerns between what's specified on the wiki and what's in this main spec is unclear to me (what if we find contradictions later?). On the other hand, I see that implementors should be made aware of this protocol. Perhaps you can just have a section "Common external protocols defined so far", clarify their standard status ("If you provide the protocols with the following URIs, you should regard the referenced specifications as if they were part of this specification. On the other hand, incompatible changes to protocols listed here are forbidden by this specification.") and then just enumerate ("self-documenting") URLs? (11) sect. 3.6.2 "limited to the UWS synchronous transfer endpoint" -- is there such a thing? I'd say the "UWS" needs to go from that statement. (12) In several places, there still are hardcoded section references in the document (search for "section [0-9]"; example: "section 5.5" on p. 66, which I'm pretty sure doesn't point to where it should any more). They need be replaced by label-ref pairs (I'd have done that myself, but I don't understand the document well enough to confidently do that). (13) With my hat as ivoatex author on, I remark that my recommendation is to keep physical lines shorter than 80 characters if at all possible; it makes for more informative diffs without further tooling. -- MarkusDemleitner - 2017-06-12 | |||||||
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue.
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and Validators | ||||||||
Added: | ||||||||
> > |
| |||||||
Please note your implementation or validator in this section.
Comments from Pierre FerniqueImplementation references
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Thrown Exception | ||||||||
Changed: | ||||||||
< < | It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. | |||||||
> > | It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue. | |||||||
-- LaurentMichel - 2017-05-05 Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel ) | ||||||||
Added: | ||||||||
> > | VOSpace is a rather complex standard I just discoverd by reading the paper. I appreciate the section 1.4 which is an indispensable guide for the reader
Section 1.2:
Starting a document with a typical use case is a great idea, but this section is a bit too much detailed. Something more concise withe less XML would be still more valuable Section 3.1 It is said here the VOSpace may interpret data. This a very imprortant feature to me which should be introduced before the data model section (1.2 e.g.). This is not a data model feature by the way. Thrown Exception It is said in some places(3.4.4#Default Import View e.g.) that the service can throw exceptions. I do not see what does it mean in term of interoperatbility. Throwing or not exceptions is rather an implementation issue.
-- LaurentMichel - 2017-05-05 | |||||||
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Change since last version
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Create Node | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Transfering data
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Transfers
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: The original 20170405 PR can be found here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
From version 2.1-20140805:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. | ||||||||
Changed: | ||||||||
< < | The VOSpace 2.1 Proposed Recommendation can be found at: | |||||||
> > | The latest VOSpace 2.1 Proposed Recommendation, with updates from feedback on this page, can be found at: | |||||||
Changed: | ||||||||
< < | And here: | |||||||
> > | The original 20170405 PR can be found here: | |||||||
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. Comments from Pierre FerniqueImplementation references
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Introduction | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Typical use of a VOSpace service
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace data model | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Property identifiers | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Property descriptions | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Standard properties
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
View descriptions | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
REST binding
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Message schema | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
-- PierreFernique - 2017-04-11
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The VOSpace 2.1 Proposed Recommendation can be found at: And here:
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section. | ||||||||
Added: | ||||||||
> > | Comments from Pierre Fernique | |||||||
Added: | ||||||||
> > | Implementation references
| |||||||
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The VOSpace 2.1 Proposed Recommendation can be found at: | ||||||||
Changed: | ||||||||
< < | And here (when published to the document repository): | |||||||
> > | And here: | |||||||
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
| ||||||||
Deleted: | ||||||||
< < | ||||||||
An earlier VOSpace discussion page can be found here:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section.
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|
VOSpace v2.1 Proposed Recommendation: Request for CommentsRFC page for the IVOA VOSpace 2.1 Proposed Recommendation. The VOSpace 2.1 Proposed Recommendation can be found at: And here (when published to the document repository):
Change OverviewThe change notes since version 2.0: From version 2.1-20170405:
An earlier VOSpace discussion page can be found here:
Comments from the IVOA Community during RFC period: 2017-04-06 - 2017-05-18
Implementation and ValidatorsPlease note your implementation or validator in this section.
Comments from TCG members during RFC period: 2017-04-06 - 2017-05-18WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery in Databases Interest Group ( _ Kai Polsterer_ )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)
<--
|