TAPRegExt-1.0 Proposed Recommendation: TCG Review

This document serves as the RFC center for the Proposed Recommendation entitled "TAPRegExt: a VOResource Schema Extension for Describing TAP Services, Version 1.0".

The latest version of TAPRegExt:

• http://www.ivoa.net/Documents/TAPRegExt/

Reference Interoperable Implementations

• TOPCAT (client)
• GAVO data center and the underlying software DaCHS software (server)
• CADC TAP service: the VOSI-capabilities resource includes extended metadata defined in TAPRegExt-1.0

Implementations Validators

Any schema validator will do for syntactic validation. STILTS' taplint task does a partial semantic validation.

The OpenCADC TAP library contains a TAPRegExtParser that performs full schema validation on VOSI-capabilities documents with TAPRegExt extended metadata.

RFC Review Period: 14 February 2012 - 13 March 2012 (closed)

TCG Review Period: 16 March 2012 - 14 April 2012 (open)

---

---

Comments from the IVOA Community during RFC period: 09 February 2012 - 08 March 2012

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.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comment from Mark Taylor

The example document in Appendix B has similar upload specifiers in two formats, e.g.

<uploadMethod ivo-id="ivo://ivoa.org/tap/uploadmethods#http"/>
<uploadMethod ivo-id="ivo://ivoa.net/std/TAPRegExt#upload-http"/>

The second form corresponds to the upload method sanctioned by this standard, but the first form corresponds to an earlier version of this standard. Although it's legal to declare non-standard upload methods, and it might make some sense (for the near future) to have both versions in a production service to cope with clients written against the earlier version, it's confusing to have this in an example contained in the standards document. I suggest removing the out-of-date versions and just retaining the ..std/TAPRegExt#.. uploadMethod elements in this example. At the very least comment what these apparently redundant declarations are doing here. -- MarkTaylor - 09 Mar 2012

Oops -- that was an editorial oversight. The obsolete ivo-ids are gone from current SVN (r1648). -- MarkusDemleitner - 12 Mar 2012

---

---

Comments from TCG member during the TCG Review Period: 16 March 2012 - 14 April 2012

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

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

TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)

A minor update should be made to the Architecture Diagram as VOSI has now been approved as a REC. I'll send the updated figure to the author.

I approve the document. -- ChristopheArviset - 20 Mar 2012

Applications Working Group (Mark Taylor, Enrique Solano)

There is a small number of errors:

• All the schema snippets in the text lack the xs: prefix on close tags (e.g. <xs:sequence>...</sequence> )
• The upload example in Sec 2.5 says "...retrieving from ftp and http URLs..." but the example declaration lists http and inline upload types.
• "Pricscilla" should read "Priscilla" in the [XSD] entry in the bibliography.

There are also a couple of issues related to VOTable:

1. Sec 2.4 references the "yet-to-be-defined BINARY2 VOTable element"
2. The example in Appendix B uses the parameterised MIME type application/x-votable+xml;encoding=tabledata . The definition of the "encoding" parameter for the VOTable MIME type has been discussed, but is not currently part of any standard.

Although it is still to be decided whether BINARY2 will be endorsed in a future version of VOTable, I think it's OK to include the qualified reference as it stands. However, I'd be inclined to strip the parameter from the quoted MIME type in the example, especially since there is no explanation that this is not (currently) a standard usage.

Following consideration of these points, I'm happy to recommend acceptance of this carefully written document. -- MarkTaylor - 26 Mar 2012

Author comments:

• prefix missing on closing tags: Fixed in ivoadoc, SVN rev. 1663
• Upload example: Fixed in the prose
• Bad reference: Thanks

On encoding=tabledata -- I'd like to hear more opinions on this before throwing it out (it would mean another edit to what is otherwise basically a pretty-printed dump of a live and validated document, which is one reason I'm reluctant). For now, I've added prose clarifying it's not an IVOA-endorsed MIME-type.

All changes should be in SVN rev. 1664.

-- MarkusDemleitner - 27 Mar 2012

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

Data Model Working Group (Jesus Salgado, Omar Laurino)

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

I'm happy to approve this. -- AndreasWicenec - 17 Mar 2012

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

I approve. -- GretchenGreene - 20 April 2012

Semantics Working Group (Sebastien Derriere, Norman Gray)

VOEvent Working Group (Matthew Graham, John Swinbank)

There are a number of issues with this document:

• There is no mention made of dependencies on the VODataService standard, either in the IVOA Architecture, the text or the full schema (missing namespace declaration?) yet it is imported in the schema and required in the example instance for the xsi:type of the interface.
  • the import of VODataService in the schema was a mistake (fixed in SVN, has no functional effects). Otherwise, VODataService is used in the interface declaration exclusively, which I'd consider VOResource territory. So, while I'd easily be swayed, I'd say VODataService need not be mentioned as an explicit dependency of TAPRegExt (the interface type might even change without changes to TAPRegExt). -- MarkusDemleitner - 19 Apr 2012
• Mention is made of capabilities, capabilities (in type face) and - this is confusing (a comment I've had levelled against me in the past)
  • I'm not sure I understand this comment. Maybe an example of a change to fix this would help? -- MarkusDemleitner - 19 Apr 2012
  • See the info box in sec 3.1 of the VOSI spec -- MatthewGraham - 19 Apr 2012
• Sec. 2.1: The RI standard requires xsi:schemaLocation, the document recommends it and VOResource authors may choose to use it - this is very ambiguous.
  • I've tried to make the intention somewhat clearer and tone down the admonition in SVN. Is it better this way? -- MarkusDemleitner - 19 Apr 2012
• ivo-id attribute: the first reference to this declares it (in both the text and the schema) to be of type vr:IdentifierURI; all subsequent mentions of ivo-id say that it is 'xs:anyURI', despite representing an optional IVORN.
  • ivo-id -- I give you that it's a bit unfortunate that like-named attributes have differnt types. The background is that a data model's ivo-id will always (I hope) refer to a full resource record, whereas for language version, output format, or upload method the reference will go into a resource record and hence require a fragment identifier; these, however, are not allowed in vr:IdentifierURI. If this doesn't convince you, I guess we could either change the type of the ivo-id type for the data model or use a different attribute name in the other instances -- MarkusDemleitner - 19 Apr 2012
  • I think this reasoning is fine but it should be explained in the document - I thought someone was just being lazy or forgetful -- MatthewGraham - 19 Apr 2012
  • There's now prose that tries to explain it in svn rev. 1707; however, when writing it I realized that the way things are written, there's a conformance requirement that these things are indeed IVORNs that's not enforced by the schema. I'm almost tempted to introduce a new type IdentifierURIWithFragment, but I'm reluctant to do this this late in the process -- MarkusDemleitner
• The standardID attribute on the capability element for TAPRegExt is not specifically defined anywhere in the text - just quoted in examples
  • I've added prose to fix this -- MarkusDemleitner - 19 Apr 2012
• Sec 2.3: If ADQL 2.0 is mandatory for TAP services then the schema should include this as a required value in the list of languages in any instance
  • I'd rather not put this in the schema. Frankly, I don't think someone's TAPRegExt should be invalid if they choose not to implement ADQL; sure, their service might be, but I think this is the wrong place to punish them -- MarkusDemleitner - 19 Apr 2012
  • A TAP service that does not implement ADQL is non-compliant; a TAPRegExt without an ADQL language reflects a non-compliant service but is a compliant TAPRegExt. For service compliance, both will need to be fixed so really the TAPRegExt should be wrong from that perspective. -- MatthewGraham - 19 Apr 2012
• Sec 2.7: The absence of upload methods indicates that the service does not support uploads at all:
  • Would it be better to have a specific value of the attribute that addresses this?
    • Possibly. But I'm confident this proposal will work robustly. -- MarkusDemleitner - 19 Apr 2012
  • Does the absence of retentionPeriod, executionDuration, outputLimit, and uploadLimit attributes have similar indications about no retention period, etc.?
    • No. I'd venture to suggest the language "TAPRegExt's capabilities element allows the declaration of such limits. These declarations are primarily intended for human consumption and should give conservative guidelines." should indicate that they are not intended to allow inferences about a service's operation. If you disagree, I'll be happy to add language that make this somewhat clearer. -- MarkusDemleitner - 19 Apr 2012
    • Interpretation of absences is a common source of confusion of IVOA specs so whilst something may appear obvious - "we never meant that" - extra text specifically spelling it out is often not a bad idea. Given the behaviour of upload methods, it might be good to add a sentence or two that the other attributes do not function in the same way. -- MatthewGraham - 19 Apr 2012
    • That's already in place -- sect. 2.6 says: "Note that the absence of a specification of limits does not imply that no limits are enforced." -- MarkusDemleitner - 23 Apr 2012

Typos, style, etc. (based on the PDF version):

• Status of this Document: "which may be changed before it is accepted as a full..." - this sentence just hangs.
  • fixed in ivoapub rev. 1704 -- MarkusDemleitner - 19 Apr 2012
• Consistent capitalization of schema/Schema
  • It's now lowercase except where the actual standard "XML Schema" is referred to -- MarkusDemleitner - 19 Apr 2012
• Consistent citation: ([REF]) vs. (see [REF])
• Conformance-related definitions - other IVOA standards have text about the use of "MUST", "SHALL", "SHOULD', "MAY', "RECOMMENDED" and "OPTIONAL'. This is missing from the preamble of the document but stylistically from the body of the text: for example, sec 2.1: "The namespace associated with TAPRegExt VOResource extensions will be..." - this ought to be "shall be" at least.
  • I've left out the RFC 2119 modal verbs rather on purpose; the document basically is a comment to an XML schema, and the schema is the exact representation of the standard. I'd therefore consider RFC 2119 language a bit too bombastic. But again, I'd be easily swayed here. As to the "will be", I've changed it to "is" in SVN. -- MarkusDemleitner - 19 Apr 2012
  • The usage of RFC 2119 language is fairly consistent throughout Registry (and GWS) specs -- MatthewGraham - 19 Apr 2012
• Syntax Notation Using XML Schema: Is there a missing reference to the VOResource schema?
• 1.1, TAP, v1.0: "The TAP standard describes some of the concepts the declaration of which..." should be "The TAP standard describes some of the concepts, the declaration of which..." - similar for UWS, v1.0.
• Sec 2.2: "a data model is identified by its IVORN" - give a reference to the IVORN spec.
• Sec 2.4: In the definition of tr:OutputFormat Attributes - "look for keys starting with output-" would be less confusing if quotes were placed around 'output-'
• What is "RofR" in the schema documentation (Version complexType?
• LanguageFeatureList complexType: "mandatoy" should be "mandatory"
• LanguageFeatureList complexType: ... - I thought HTML elements had to be namespaced in xs:documentation content viz. ...

Following consideration of these points, I'm happy to recommend acceptance of this document. -- MatthewGraham - 18 Apr 2012

all points I've not commented should be represented in SVN rev 1705. Thanks a lot for the feedback; a PDF reflecting current SVN is available at http://docs.g-vo.org/tre-svn.pdf during the reviews. -- MarkusDemleitner - 19 Apr 2012

Data Curation & Preservation Interest Group (Alberto Accomazzi)

Knowledge Discovery in Databases Interest Group (Giuseppe Longo)

Theory Interest Group (Herve Wozniak, Franck Le Petit)

Standards and Processes Committee (Francoise Genova)

---