IVOA Identifiers V1.1 RFC

This document will act as RFC centre for the "IVOA Identifiers" v1.1 (RayPlante, editor).

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

Discussion about any of the comments or responses should be conducted on the virtual observatory query language mailing list, registry@ivoa.net.

Community Comments

• First sample comment (by TonyLinde): ...
  • Response (by authorname): ...

• At the Victoria interop I think we agreed that it would be a good idea to explicitly ban the use of "!" in identifiers, as that would have a special meaning in the VOSpace vos: scheme. The document as stands does not include this ban.
  • Accepted. The ban has been included as requested. (RayPlante - 22 Aug 2006)

-- PaulHarrison - 27 Jun 2006

Thre is still a little confusion in the revised document about whether "!" can appear in the resource key, although the ABNF list of reserved characters in version 3.1.1 now contains "!" the text that quotes them in the 2nd paragraph of 3.1.2 for the resource key does not - it would perhaps be better to remove the list in 3.1.2 and just make a link back to the ABNF.

-- PaulHarrison - 12 Oct 2006

• • thanks for pointing out this other location requiring the update; I will update accordingly. I will certainly add the link; however, the text needs to refer to it in a non-hypertext way so that it is clear when reading a printed copy.
    -- RayPlante - 13 Oct 2006

Comments from the Technical Coordination Group

TWG members should add their comments under their name. The deadline for comments is 27 Oct 2006.

Mark Allen (Applications IG)

I approve.

Minor textual comments:

Introduction:

of the first type describe above...

-> of the first type described above...

3.1.1

Incomplete sentence in the Note:

...;this practice has the advantage of reducing the probability that two authority ID.

3.3.2 Typo in the Note: concatonated -> concatenated

Francoise Genova (Data Curation & Preservation IG)

please edit

Bob Hanisch (Standards & Documentation WG)

Speaking with minimal/no authority, given that S&D WG is inactive, I approve and, like the others, only suggest that the typos be corrected.

Gerard Lemson (Theory IG)

I approve.

Jonathan MacDowell (sic) (Data Models WG)

I approve the rec. Please fix the 'concatenated' (latin: /catena/, chain) typo (and while you're at, please note for future RFC's that I'm Mc, not Mac :-)).

I did find it a bit confusing in places to figure out what rules were specific to this doc and what were merely echoing standard W3C URIs etc. - you might consider adding e.g "IVOA reserved characters" for "reserved characters". But it doesn't really affect implementers, so it's not a big deal.

I agree with Doug that it would be better to just accept case insensitivity. As I read the doc, I infer that Dataset IDs are not necessarily case insensitive following the stop character that terminates the resource identifier, since that part of the string is not (?) restricted by this document.

Reagan Moore (Data Curation & Preservation IG)

I approve the recommendation. There are a few minor typos that can be corrected: section 1.0 - replace "control of provides" with "control provides" section 3.1.2 - replace "has complete control their forms" with "has complete control of their forms" section 3.2.2 - replace "that a URI that refers" with "that a URI refers"

Francois Ochsenbein (VOTable WG)

After the correction of the typos already mentioned, and a fixing of the many problems existing in the links (e.g. Berners-Lee in the references is assigned "uri" as a name, but referred as "ber1998"; in the framed note of section 3.1.2 reserved link gives an error; etc); after making the list of reserved characters consistent between the enumeration and the BNF definition in section 3.1.1; and maybe explain why some of the characters which are excluded in URIs (section 2.4.3 of RFC 2396) are included in the reserved list (e.g. angle brackets) but some others are omitted (e.g. the percent or double-quote); then I would approve the document.

A last question: why not include in the discouraged list all the unwise characters of RFC 2396 ?

Pedro Osuna (VOQL WG)

Point 3.1.1 list of discouraged characters is missing the following ones to be in sync with the ABNF: "&" "$"

As above in 3.1.2 for the characters: "!" "&" "$"

The XML schema in the appendix refers (in the documentation section) to "version 0.1" while it should be 1.1

I approve the recommendation once this very minimal changes are introduced

Ray Plante (Resource Registry WG)

Submitting Chair: no comments.

Andrea Priete-Martinez (Semantics WG)

I approve.

Guy Rixon (Grid & Web Services WG)

I approve.

I note that the XML serialization stated in the appendix -- Identifier as a complex type with element children -- is not that used in the current registry schemata.

I further note that VOSpace would be easier to implement the separator character in resource keys was something other than '/'. However, I realize that there are too many existing identifier containing '/' to change this now.

Doug Tody (Data Access Layer WG)

I approve the recommendation with the following minor comments.

Section 3.1.1 recommends that applications present identifiers using all lower-case characters, while 3.1.2 notes that mixed-case may be used to improve readability. Since comparisons are already case-insensitive I suggest that we uniformly allow case to be used to improve readability and not discourage the practice.

Suggesting that the resource key is intended only for human consumption and is not semantically machine-interpretable is clearly not correct. Perhaps what is meant is that the content of the resource key has no meaning within the context of the IVOA as defined by this document (it may have meaning to a data provider or consumer).

3.2.2 Typo: "In addition to the syntax to the above syntax..." 3.2.2 Typo: "concatonated"

I am pleased to see the discussion in 3.2.2 of dataset identifiers. I was originally concerned (around page 5) that as the spec was written dataset identifiers were not legal IVOA identifiers, but eventually determined that the IVOA merely claims to recognize only the collection and that the full dataset identifier syntax is nonetheless legal.

Nic Walton (GGF Astro-RG)

please edit

Roy Williams (VOEvent WG)

please edit

Additional comments from Registry chair

I accept all recommendations regarding typos and sentence syntax.

Francois brings up a very good point regarding consistancy with RFC2396. I will eliminate all characters from the reserved list that are already disallowed by the URI syntax and generally clarify things.

-- RayPlante - 05 Dec 2006