Formal Objection: SPARQL Protocol for RDF Did Not Fulfill Its CR Exit Criteria

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