Difference: RegistryInterface101RFC (10 vs. 11)

Applications (Tom McGlynn)

Document says it's a working draft, but it is actually a Proposed Recommendation -- that seems to be a general problem.

1.1 I don't believe that it is ever clearly stated that the functional distinction between a publishing registry and a searchable registry is that a publishing registry does not support the search functions of section 2. The statement is made that "it does not need to support...". I think a clearer statement would be something like:

Only searchable registries support the protocols discussed in section 2. All VO compliant registries must support the protocols discussed in section 3.

2.1 I don't see what advantage there is in making the distinction between search and resolve operations.

Note that getResource presumably returns 0 resources if the ID is not known (i.e., it is not "one and only one")

2.1.1 It seems to me that the error response should be something that is standardized at a higher level than a specific protocol. Too late for that though I suppose.

It was unclear to me if the paging of results is done purely at the request of the user or can be initiated by the server if some constraint is exceeded (as in the OAI interface). Could this be clarified.

2.1.2 the "hitherto referred to using the "adlq:" prefix" doesn't make sense, since as far as I can tell it was never used up to that point. Do you mean "from now on..." --- that's the opposite of hitherto?

I don't like the idea of a required attribute being set to a null value with Table. Personally I'd prefer some string, e.g., "Registry".

I have no idea what the adql:Column elements look like and I think you should give an example here, or replicate the appropriate item in the schema if it's short enough.

Why must there be an implicit addition of the status requirement? This is redundant with a statement in 2.1.1 I think. [Personally I think this is not necessarily a good idea. What if I want to know how many records in a registry have been deleted. These is no way to do this using the search interface even though it is a trivial query to formulate. Maybe some kind of flag allowing old records shoudl be available.]

2.1.2.1 is very confusing to me. Move the examples up and put them in the text rather than a box even if they are non-normative.

The first note in 2.1.2.1 is mystifying to me. I'd make it a footnote.

In the note about harvesting... I'm not sure what this means? Am I forbidden to harvest using these methods? I don't think so -- I certainly hope not. We don't tell users what they cannot do. We tell them what they can. I think this note is meaningless. We can recommend use of the OAI protocols for harvesting but that's as far as we should go.

The last note in this section -- which seems to be mostly notes! -- is also somewhat mysterious. I think the issues raised in the first and last notes should be discussed more clearly in a non-normative appendix.

2.1.3 I'm concerned about white space. If the registry contains a field which has two consecutive blanks then I gather that I cannot match against it since consecutive white space on the input is to be compressed to a single white space.

The document suggests that all white-space characters in the search field match all white-space characters in the registry text. E.g., space in the input matches a carriage return in the text.

How about just saying something like: The keyword value is a string where leading and trailing white space is discarded. The string is broken into keyword tokens using white space delimiters except when the white space is enclosed in quote(e.g. ...). The characters ... are considered white space. A token that begins and ends with "'s has them removed.

and leave off any mention of compression.

By the by, is there an escape mechanism for quotes? Currently I don't think I can look for the string " can" versus "can" or for "can not" versus "can not". I don't see why these are explicitly precluded.

I'd put the note in the main text.

2.2.1

Personally I'd just reuse the output format from the search.

2.2.2

If "Not found" is thought to be an error, it should give an error response. If it isn't an error, then don't say an "error message" should be added. The use of the "fault" seems to be an effort to sidestep the word error but makes everything less clear to me.

Personally I'd suggest treating NOT FOUND as a perfectly natural response to GetResource but I think the corresponding action for getIdentity is an error.

2.2.3 I suspect "hitherto" is again being misused -- though "vg:" does appear once previously.

3.1.1 Is the last item in the list of OAI-PMH useful features "deleted records not returned" a requirement of OAI? I'm not sure if the HEASARC is compliant if so.

3.1.2 What is the reason for the "strongly recommended"? It seems to me that this relates to one of the notes in 2.1. I don't think there is any status called strongly recommended. There is MUST and SHOULD. Require it if it's really necessary.

3.1.3 Make the note a footnote. It's irrelevant to use within the VO.

3.2 I believe the discussion of the validation level belongs in the text not in notes. Perhaps a whole section to itself!