SimpleDALRegExt v1.1 Request for Comments

This page contains public discussion of the SimpleDALRegExt 1.1 Proposed Recommendation.

Latest version: http://ivoa.net/documents/SimpleDALRegExt/20161124/index.html

(Build with changes from RFC ("SVN HEAD"): http://docs.g-vo.org/SimpleDALRegExt.pdf)

Reference Interoperable Implementations

The main relevant change to the widely-deployed 1.0 is dropping the hard link between capability class and standardID. Registry records already published conforming to the new schema include:

• CSIRO ASKAP SDA, ivo://au.csiro/casda/sia2
• GAVO Heidelberg, ivo://org.gavo.dc/__system__/siap2/sitewide

The WIRR registry interface already matches against the new standardIDs. See, for instance, this query for a query that finds a new-style image service.

Validators

SimpleDALRegExt records can be validated using any XML schema validator.

Comments from the IVOA Community during RFC period: 08 July 2016 - 31 Aug 2016

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Example comment

I'm not sure I possess the neutrality desirable for a reviewer.

-- MarkusDemleitner - 2016-07-06

Implementation feedback

With the revision of the SIA-v1.2.xsd on volute I've been able to update the CASDA registration to include the extra metadata for SIA2.

I did notice that in the SIA 2 example on page 33 of the PR, the standardId is incorrect. It is currently "ivo://ivoa.net/std/SIA#sync-2.0" but should be "ivo://ivoa.net/std/SIA#query-2.0"

-- JamesDempsey - 2016-08-11

Good catch, thanks. Fixed in volute rev. 3505 -- Markus

Comments from TCG member during the TCG Review Period: 08 July 2016 - 15 Sep 2016

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler)

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Three points. Only the first one requires a response.

• Section 3.3.1 - page 14 - "By the IVOA Note on Discovering Data Collections (Demleitner and Taylor, 2016), the standard identifier for an auxiliary SIA version 2.0 capability would be ivo://ivoa.net/std/SIA#query-aux-2.0.". Except if I'm wrong, the auxiliary capability concept has not been defined yet in any IVOA standard, only in a recent IVOA note (http://ivoa.net/documents/Notes/DataCollect/20160108/NOTE-discovercollections-1.0-20160108.pdf). Well, I'm really uncomfortable with this kind of note dependies, even if I have nothing against this new concept of "auxiliary capability". In fact, decision had been taken at a previous TCG meeting to avoid simple note dependencies (Hawaii ?). As this example is not really essential in this SimpleDALRegExt document update, I would suggest to just remove it (and the associated sentence in Change B section).

I had hoped the discoverdependent note would be endorsed by the time SimpleDALRegExt would get this far. That's not happened, in part because the EN process isn't quite defined yet. Once it is, I'd strongly argue it's citeable from RECs and future DAL standards should define their auxiliary capabilities (and their registry extensions) themselves. For now, I've moved SIAv2's aux capability id to the discoverdepent note. Change is in rev. 3547. -- MarkusDemleitner - 2016-09-14

* Section 3.1.1, 3.1.2, and following - the specified standardIDs are written with a final ponctuation: dot (.) or comma (,) followed by a carriage return - It is probably evident for the majority of readers that this character is really a ponctuaction and not a part of the standardID, but I would suggest to remove this ponctuation for avoiding a wrong possible usage (for instance, a cut&paste) of "ivo://ivoa.net/std/ConeSearch." rather than "ivo://ivoa.net/std/ConeSearch"

* Page 17 - quotations => „Cutout”, not homogeneous in all document => "query", "minimal"

For the punctuation, I've added blanks in the displayed ids. In run-in ids, I felt it's just too ugly and the risk for confusion is minimal in the first place (rev. 3558). The bad quotation marks had already been fixed in rev. 3443. Thanks! -- MarkusDemleitner - 2016-09-14

-- PierreFernique - 2016-09-09

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

-- Editorial matters:

page 7, the reference for SIA (Dowler et al 2015) is inconsistent with the version (1.0) as already stated by MarcoMolinaro on the mailing list. Due to other concerns, we don't recommand to put the reference to version 2 there.

No, that is on purpose -- the main reason for the new version is to let people use SIA capabilities for SIAv2 services. -- MarkusDemleitner - 2016-10-19

page 8 : with this specifcation ---> with this specification.

page 20 : "the name space prefix ssap:," ----> "the name space prefix ssap:"

Both fixed in rev. 3646, thanks. -- MarkusDemleitner - 2016-10-19

-- On the content:

TestQuery for SIA doesn't seem to be consistent with SIAv2.0 as far as I understand (overwise I would be happy to see this point clarified ?).

I'm now (rev. 3646) writing "It provides a region of interest (plus optionally additional parameters) to be used to get a non-empty result from the service. For SIAv2, this region of interest would usually be translated into a RANGE query." Does this address your concern? -- MarkusDemleitner - 2016-10-19

Again "imageserviceType" is fully adapted to SIA V1.0. Not to SIAV2.0 which only has something like "archival" in SSA

For now -- it doesn't hurt to be prepared for future developments (also, I'd say an atlas-type service could be based on SIAv2; the semantics for non-positional queries would be a bit tricky, but there's nothing in the standard that forbids this kind of thing). -- MarkusDemleitner - 2016-10-19

In Appendix A , the example shows a SIAV2.0 capability where the interface will be different than the one for SIAV1.0 (parameter list is different) which is somewhat in contradiction with the statement ""it turned out that versioning of IVOA standards now occurs on the capability level rather the interface level". For these reasons I would like this Appendix to be slightly modified and to announce an endorsed note for details.

The statement about interfaces vs. capabilities refers to the original VOResource 1.0 plan, where a single capability would have had multiple interface elements with differing @version elements. What indeed happened is that different capability elements are used to house the differing interfaces. I'm not sure how to better express this, but i'd gladly accept suggestions. -- MarkusDemleitner - 2016-10-19

An attempt " it turned out that versioning of IVOA standards now (typically) makes use of different capability elements rather than simply different interface elements in the same capability". -- FrancoisBonnarel -2016-11-23_

I've taken this up (and removed some additional confusing text) in rev. 3742. Thanks -- MarkusDemleitner - 2016-11-24

Apart from this little (but important) point we fully support this standard.

-- FrancoisBonnarel

-- MarcoMolinaro

-- 2016-10-18

Data Model Working Group ( _Mark Cresitello Dittmar, Laurent Michel )

Some comments, mostly minor as I'll try to keep them on the deltas from 1.0.

Title page: the 'Previous versions' list does not include any earlier drafts of the V1.1 document.. I don't think we have a convention for this.

Indeed, I forgot to add the WD; it's added in rev. 3596. This clearly needs some sort of tooling -- MarkusDemleitner - 2016-10-05

Abstract: typo = "VO Supoort Interfaces (VOSI)" s/b "Support"

...which goes to show how important it is to be extra careful when applying last-minute fixes -- MarkusDemleitner - 2016-10-05

Syntax Notation: sentence in search of a reference.. " change over time according to the rules laid out in ?."

Bibtex entry was forgotten. Fixed in rev. 3596 -- MarkusDemleitner - 2016-10-05

Section 3.2.1: connected with the comment below.. if I read this correctly, the identifier is the only thing in Section 3.2 which applies to SIA-v2, everything else applies only to SIA-v1.1. If this is true, then I don't think it should be mentioned at all. If anything, it could be mentioned in the 3.2 main description, but I think that sets a precedent for updating this document every time another protocol correctly defines the metadata in its own document.

No. The capability applies to SIAv2 as well, which is the main reason for making this spec in the first place. I've added some language to that effect in the opening paragraph of 3.2. (rev. 3596) -- MarkusDemleitner - 2016-10-05

SIA-v2:

I think the content w.r.t. sia-v2 has changed over the iterations. If I read this correctly, there is currently no dependency on sia-v2, which correctly defines this information itself, and will add content as the capabilities grow in upcoming revisions. If that is true, it seems more appropriate not to mention it at all. The 'best-case' scenario is that all protocols define this metadata themselves, this only includes the earlier ones because they do not.

I agree it would be preferable to maintain these Registry extensions in the respective standards in the future, and I'm planning to try and see to it that that is the case (cf. SimDAL, VO-DML). However, for SIAv2 that is not the case; all it does is define a standardID. This is enough to communicate the fact that a capability conforms to the standard, but not to communicate the extra SIA metadata. -- MarkusDemleitner - 2016-10-05

Cuts and deprecations of XML schema and ProtoSpectralAccess seem approprite.

I don't consider any of the above show-stoppers, though I would appreciate a response to the SIA-V2 comments to be sure I understand things correctly.

-- MarkCresitelloDittmar - 2016-10-04

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

• Two references to VOSI say VO Standard Interface rather than VO Support Interfaces (in the abstract and at the very bottom of section 1)
  • fixed in Volute rev. 3593 -- MarkusDemleitner - 2016-10-04
• Since you are mentioning non-optional elements in the last paragraph of section 2, you could mention that an interface may have a securityMethod element that identifies the type of credentials recognized on that interface.
  • Hm -- this is talking about the description of protocol parameters (assuming we're both talking about p. 9, roughly center). So, when trying to fit a mention of securityMethod in there, I had a bit of a hard time and eventually gave up. I'll happily accept patches, though. -- MarkusDemleitner - 2016-10-04

Overall, a well written and clear document. I approve.

-- BrianMajor - 2016-10-03

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Minor copyediting:

Typo/needs update? 1.2 Dependencies / Typed DAL Products: aren't we now relying on SIAv2 as it's the recommended version? Either text should be changed or the link should be changed to the static old version.

3.3: Has German quotation marks as they are not used elsewhere.

Referencing SIAv2 since rev. 3558. Thanks! -- MarkusDemleitner - 2016-09-14

I approve of this reorg and consolidation of the basic RegExt standards. I also appreciate the expanded appendix on multiple service versions/interfaces as this is increasingly an issue resource providers need guidance on in practice.

-- TheresaDower - 2016-09-07

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

We approve the document. the controlled vocabulary mentionned in this specification is covered in the XML schema. I also emphasize the help of examples in the document.

-- MireilleLouys - 2016-10-21

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )

Data Curation & Preservation Interest Group ( Françoise Genova )

Knowledge Discovery in Databases Interest Group ( Kai Lars Polsterer )

Operations Interest Group ( _Tom McGlynn, Mark Taylor )

Ops IG recommends acceptance. -- MarkTaylor - 2016-09-22

Theory Interest Group ( _Franck Le Petit )