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)

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.
• Mention is made of capabilities, capabilities (in type face) and - this is confusing (a comment I've had levelled against me in the past)
• 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.
• 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.
• The standardID attribute on the capability element for TAPRegExt is not specifically defined anywhere in the text - just quoted in examples
• 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
• 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?
  • Does the absence of retentionPeriod, executionDuration, outputLimit, and uploadLimit attributes have similar indications about no retention period, etc.?

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.
• Consistent capitalization of schema/Schema
• 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.
• 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

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)

---