- From: Sean B. Palmer <sean@miscoranda.com>
- Date: Wed, 14 Nov 2007 09:47:54 +0000
- To: public-rdf-dawg-comments@w3.org
The SPARQL Protocol for RDF did *not* fulfill its CR exit criteria, and should not have gone to PR. I am raising again the criterion that it failed to fulfill as a Formal Objection to the PR, so this complaint must receive Director consideration before the specification goes to REC, amongst other requirements mandated by W3C process as noted below. The criterion which was not fulfilled is as follows: [[[ The design has stabilized and the Working Group intends to advance this specification to Proposed Recommendation once the exit criteria below are met: [...] Relevant media types are registered: [...] * The SPARQL protocol specification uses the ext/rdf+n3 media type, which is unregistered, in an example ]]] - http://www.w3.org/TR/2006/CR-rdf-sparql-protocol-20060406/ The text/rdf+n3 media type has not yet been registered; it does not appear in the following list as of 2007-11-14: http://www.iana.org/assignments/media-types/text/ Therefore the following is false: "The Working Group has satisfied the exit criteria set forth in the 6 April 2006 Candidate Recommendation" - http://www.w3.org/TR/2007/PR-rdf-sparql-protocol-20071112/ The WG's request to go to PR was as follows: http://www.w3.org/2001/sw/DataAccess/prq819 - Transition Request: three SPARQL specifications to Proposed Recommendation by Lee Feigenbaum, for the RDF Data Access Working Group, October 2007 It does not mention text/rdf+n3. Information is recorded as to the other media types: [[[ IETF review of SPARQL related media types (application/sparql-query, application/sparql-results+xml) began with review requests (query review request results review request on 24 Nov 2005 and were repeated (query review request, results review request) on 9 Mar 2006. We have not received any comments as a result. ]]] These media types have been registered as part of a W3C specification, so this is correct procedure as I understand it. The situation for text/rdf+n3 is very different: it has not even been properly submitted, as can be deduced from the following: [[[ Tim: Tim sent some mail to get text/n3. What happened to it? Ted: where? Tim: see Application for MIME Media Type Tim: the script above gives you back a number. <timbl> 5004 Ted: a different process for SDO than for individual/company How to Register an Internet Media Type for a W3C Specification Tim: text/n3 doesn't have any standard status. I'd like to reserve it. <DanC> (registration of this mime type is a CR exit criterion for SPARQL, currently. http://www.w3.org/2001/sw/DataAccess/crq349 ) Ted: you could do that, but we will need an internet draft. Procedures for registering MIME Types can be found in [RFC4288],[RFC4289]. The ones linked from Application for MIME Media Type are deprecated. Ted: the registration depends on the use. we could reserve it and it can be changed later. it's much better if those specs don't change. as long as there is a version spec, we shouldn't have a problem for it. Tim: it's important to know which version you refer to at any time, this still allows changes. Ted: if you point to the previous one, you still need to be ok. Mark: if you want to be in the standard tree, like text/, this takes more time. Tim: my concern is the system isn't clear. <timbl> text/rdf+n3 http://www.w3.org/DesignIssues/Notation3 Leslie: this seems to fall into a general category of things to clean ... if somebody writes a note about this, I can champion it in the rigth places. Ted: as long as I have a formal w3c publication (to be defined by W3C) or an internet draft, I can move it forward. <DanC> tim, then you'd be in the http://www.w3.org/2002/06/registering-mediatype process ]]] - http://www.w3.org/2006/11/01-ietf-minutes.html#item06 Leslie Daigle said that he'd champion the case if a note was written; and Ted Hardie said that he can move it forward if text/rdf+n3 were defined by a specification or Internet-Draft. The latter has not happened, and I don't believe that the former has happened either since no ACTION was assigned as a result of this item in the minutes. The Notation3 specification which defines text/rdf+n3 states that the request is pending per the submission that Tim noted as "5004": [[[ The application for text/rdf+n3 with the IANA registry is pending as of 2006-02 as IANA #5004. While registration is pending, applications should use the proposed type in anticipation of registration, not an x- type. ]]] - http://www.w3.org/DesignIssues/Notation3.html But that is not the case. You need IESG approval, which hasn't been requested; there is no W3C specification or Internet-Draft to base it on. IANA would then act in response to the IESG decision as announced on ietf-announce. RFC 4288 states that ietf-types SHOULD review all external submissions of media types, but I downloaded the entire ietf-types mail archives and there isn't a single mention of text/rdf+n3. Moreover, text/rdf+n3 may prove to be a contentious media type submission. Just a few days ago a thread on www-rdf-comments erupted with dissension about this media type: http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/thread#msg1 - N-Triples MIME type should not be text/plain -- comment on RDF Test Cases. (I do not personally believe that text/rdf+n3 should not be registered, but my personal opinion does not mean that it should therefore not be subjected to formal comment and due process.) The conclusion: SPARQL Protocol for RDF must not use text/rdf+n3 without it having been registered; without it, indeed, having even been properly submitted for registration. This message is a Formal Objection per the following section of the W3C Process, which I will subsequently demonstrate that I have followed correctly: [[[ 3.3.2 Recording and Reporting Formal Objections In the W3C process, an individual may register a Formal Objection to a decision. A Formal Objection to a group decision is one that the reviewer requests that the Director consider as part of evaluating the related decision (e.g., in response to a request to advance a technical report). Note: In this document, the term "Formal Objection" is used to emphasize this process implication: Formal Objections receive Director consideration. The word "objection" used alone has ordinary English connotations. An individual who registers a Formal Objection SHOULD cite technical arguments and propose changes that would remove the Formal Objection; these proposals MAY be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration by the Director. A record of each Formal Objection MUST be publicly available. A Call for Review (of a document) to the Advisory Committee MUST identify any Formal Objections. ]]] - http://www.w3.org/2005/10/Process-20051014/policies.html#FormalObjection I am an individual, hence I may register this Formal Objection to the decision to move from CR to PR. I SHOULD, and hence will, "cite technical arguments and propose changes that would remove the Formal Objection". The argument is simply that text/rdf+n3 is not registered, that this was an exit criterion for CR, and that it has not been fulfilled. An acceptable change that would remove the Formal Objection would be that text/rdf+n3 is formally registered with the IANA and appears in the list at <http://www.iana.org/assignments/media-types/text/>. I would also be open to considering whether or not the SPARQL Protocol for RDF removing all use of text/rdf+n3 as a format is an acceptable change. "A record of each Formal Objection MUST be publicly available." This is being sent to public-rdf-dawg-comments@w3.org per the following: "Aside from formal membership reviews, comments on this document should be sent to public-rdf-dawg-comments@w3.org, a mailing list with a public archive." - http://www.w3.org/TR/rdf-sparql-protocol/ It is "a mailing list with a public archive", hence the record of this will be publically available. This message qua Formal Objection must therefore receive Director consideration in regards to SPARQL Protocol for RDF being advanced to REC, and requires that A Call for Review (of a document) to the Advisory Committee MUST identify this Formal Objection. P.S. My main practical worry includes that, for example, the specification uses text/rdf+n3 and then Tim goes through the IETF process and they manage to convince him that actually application/rdf+n3 is better, and suddenly the specification is broken. I very much doubt this will happen, but it is *possible*, especially given the objections raised in the cited www-rdf-comments thread. Having not fulfilled your exit criteria is pretty bad, process-wise; this criterion didn't receive a single mention. Thanks, -- Sean B. Palmer, http://inamidst.com/sbp/
Received on Wednesday, 14 November 2007 09:48:13 UTC