RFC Discussion

This page will be used to encapsulate the discussion of the SAMP RFC from December 8, 2008 through January 16, 2009. Comments and responses will be included below. The SAMP protocol and its implementations are described in the documents linked to the SampProgress page. Since the document is in a public source code repository, interested viewers will be able to see the changes which are made as a consequence of these comments - see SampDoc for details.

Please add your comments here directly, or send mail to either the general Applications or specific SAMP mailing lists.

---

Comments:

Comments from BobHanisch

• Most of my comments on this document are editorial in nature – proper use of which and that, punctuation, and so on. I will be happy to share a detailed mark-up with the editors. To first order, almost all uses of “which” are incorrect and need to be replaced with “that”. I strongly prefer the Oxford comma (apples, bananas, and oranges), which is the standard for the astronomical literature in the US, but I know that in some countries and in newspapers this is not used. Wikipedia has a nice discourse on this: http://en.wikipedia.org/wiki/Serial_comma .

• A general concern, though, is that it is not clear when the document is using the special words “must”, “should”, “may”, etc., in accord with RFC 2119 and when it is not. Sometimes the words appear in all-caps, but usually they do not. Sometimes the word “can” is used and it is ambiguous whether this means may, should, or must. And sometimes “should” it used when it seems like it really is a must. I note a few particular problems below, and others are in my more detailed mark-up.

• Section 1.3 introduces the term “publish”, but then it is almost immediately abandoned and replaced by “send”. Are these synonyms, or am I misunderstanding the intent?

• In Section 3.3, the string data type is described as a sequence of characters, with the examples being ASCII hex codes, it would appear. But this is not explicit and needs to be.

• In 3.8 there is an example of the use of “can”: “The message can be encoded as a map with the following REQUIRED keys... “ I am not sure what the developer is supposed to make of this. If the keys are REQUIRED, isn’t this a “must”?

• In 3.11, p. 22, 2nd bullet, there is another example: “mtype may not include wildcards.” It seems that “must” is the correct verb. There are several more “may”s in subsequent bullets that need to be clarified.

• On p.23, just above 3.12, it says “...should complete...quickly.” What is “quickly”? There needs to be some point of reference, like in less time than something else, or so as not to block some other operation, or something similar.

• In 3.12, p. 22, the section is called “Operations a Callable Client Must Support”, but immediately we see “may” language and a description of operations that the hub invokes. I find this to be confusing.

• On p. 24, there is another “...should complete quickly” with no context.

• 3.13, p. 24, ends with “... it is not to be used by the hub to signal a failed call.” Must not? Should not?

• Section 4.2, it is not clear if these are musts or shoulds.

• Section 5, p. 31, the term UCD needs to be defined and referenced.

• Section 5.3, p. 33, the first paragraph is informal and not specific. Make a decision about how and where to document MTypes and describe it here clearly.

• Section 5.4.1, all messages are described as “should”, but they seem like “must”.

Response:

• Bob, thank you for your careful reading. Some of your comments I agree with, and some I'm still thinking about. I will make a proper response shortly. In the meantime, I would be grateful to receive your "detailed mark-up". -- MarkTaylor - 05 Jan 2009

---

Comments from Working and Interest Groups:

Applications

This draft reflects the consensus of the Working Group. There are, as far as I know, no substantive controversies. TomMcGlynn

Data Access Layer

Data Modeling

Grid & Web Services

Resource Registry

Semantics

VO Event

The IVOA might consider standardizing nomenclature for pubsub. VOEvent has brokers. SAMP has hubs. Defining a hub as a broker for routing seems a bit redundant. I guess a hub would be a broker that never talks to another broker?

A solid draft - complete and self-consistent. That's a "yea" (even a "yay!") from us. RobSeaman

VO Query Language

VOTable

PLASTIC proved to be a basic interoperability component in VO; and the SAMP document adds the possibility of understanding the underlied protocol. Well written in comprehensive terms.

I approve the document. FrancoisOchsenbein

Data Curation & Preservation

No additional comments from DCP. BobHanisch

OGF Astro-RG

Theory

Approved from TIG. HerveWozniak

TCG

The document is well written, with clear reference and examples for implementation. Taking into account the already wide acceptance of PLASTIC, Annex A is particularly useful.

In section 5.3 MTypes Vocabulary, should we directly define the NOTE of web page where the list of (existing and increasing) "samp" MTypes would reside ?

I approve the document. ChristopheArviset