W3C home > Mailing lists > Public > www-tag@w3.org > March 2005

Re: SWBPD WG Resolution Regarding httpRange-14

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 28 Mar 2005 13:38:30 +0100
Message-ID: <4247FAC6.4050603@hplb.hpl.hp.com>
To: Tim Berners-Lee <timbl@w3.org>
CC: David Wood <dwood@mindswap.org>, www-tag@w3.org, public-swbp-wg@w3.org

SWBPD WG wrote:
 > - an http URI without a hash MAY be used to identify an RDF property.
 > where MAY is understood in terms of RFC 2119
 > and identify is understood in terms of RFC 3986

Tim Berners-Lee wrote:
> 1. Briefly, The SWBP WG is not the design authority for HTTP URIs,
> so it not in a position to say MAY about them. It is in a position
> to take part in the debate.

I helped choose much of the wording of the resolution, and I added MAY 
in response to a comment from another group participant that the 
resolution was insufficiently clear.

Personally, I still think MAY was an appropriate word. Going to RFC 2119 
I read:
  5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
    truly optional.  One vendor may choose to include the item because a
    particular marketplace requires it or because the vendor feels that
    it enhances the product while another vendor may omit the same item.
    An implementation which does not include a particular option MUST be
    prepared to interoperate with another implementation which does
    include the option, though perhaps with reduced functionality. In the
    same vein an implementation which does include a particular option
    MUST be prepared to interoperate with another implementation which
    does not include the option (except, of course, for the feature the
    option provides.)

I think it is very much in scope for the SWBPD WG to have, and state, a 
position about how RDF properties may be identified; and it seems wholly 
in order to point out to SW developers, and to the TAG, that a (not 
'the') current practice, and a practice that the SWBPD WG endorses, is 
to use http URIs without a hash, in some cases.

Hence, we discourage SW implementations which are not prepared to 
interoperate with this practice; which looking at the definition of MAY 
seems to be the force of this resolution.

However, I am not sure of the value of a detailed discussion about the 
wording here. The intent is clear: SWBPD WG has a strongly held position 
that current practice, including DC, FOAF, CC, in the naming of RDF 
properties is not wrong; and there is concern that the TAG may be 
considering resolutions of httpRange-14 which would make such practice 
wrong. It is clear that SWBPD WG does not have the architecture of the 
Web in its charter, but it is also clear that how to name RDF properties 
is within its scope: the resolution is worded to be within this narrower 

I hope that as the TAG move towards resolving this issue, they will bear 
in mind the excellent advice in the next para of RFC 2119:
6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
The TAG could trump SWBPD's MAY, with a MUST NOT, but would it actually 
be required for interoperation, would it really limit behavior which has 
potential for causing harm?

 >Could the SWBPWG please answer also answer the following:
 > 1. Who was the creator <http://www.w3.org/2005/moby/dick> ?
 > 2. What is the year of creation of <http://www.w3.org/2005/moby/dick> ?
 > 3. Who was the creator <http://www.w3.org/2005/moby/xyz> ?
 > 4. What is the year of creation of <http://www.w3.org/2005/moby/xyz> ?

Those are fun questions, I hope to have a go at answering them (for 
myself), later in the week.

Received on Monday, 28 March 2005 12:39:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:08 UTC