Re: (Dis)Proving that 303s have a performance impact.

On Mon 2013-Feb-18, at 07:17, Melvin Carvalho <melvincarvalho@gmail.com>
 wrote:

> I think there is an education gap but in today's world to be a 'capable programmer' you need to understand the basics of the web.  And that means to understand the basics of URI, HTTP and HTML in that order.  For example, I have spoken to the people behind tent.io, and they dont grok # URIs at all, and are barely aware of their existence.  We really need to think of ways to close this education gap, perhaps the webid spec will be a tool in this respect.

In an ideal world, people would learn things in that order, but this isn't, as you note...

> Efficiency seems to me to be out of scope at this level of discussion.  The benefit of WebID is clean modular separation of concerns, which universal interoperability.  We've mixed up the narrative by crossing architecture, advocacy and implementation details.

That is the job of a good spec, to an extent — far from mixing up in the narrative, it provides a journey from the theoretical to the practical, giving guidance around best practice along the way. Now, there may be improvements needed to wording in order to most effectively do that, but a spec which only focusses on the normative is one no developer ever likes to read.

> It was Tim that proposed making URIs a MUST as a tactic to get it to REC status.  It was widely supported at TPAC, tho of course some advanced use cases do have 303s as beneficial as has been pointed out.  It's not going to be possible to exclude their usage or allow the test suites to fail them.  But if you're going to use 303s effectively, you probably know what you're doing anyway.

Yes — people choosing 303 isn't a concern of mine; if people want to do that, that's their prerogative. My concern is people doing neither 303 nor using fragids.

> Why would people consider the fragid superfluous ... would not a new comer to a technology simply cut and paste an example to get going?

A complete novice certainly would copy and paste, yes.

On the other hand, somebody who knows 'enough', though not a lot of SemWeb, may well look at the examples, see no *obvious* reason for the fragids, see no explanation of why they're there, and knowing about them from HTML figure they're just a stylistic nicety. The fact is that in RDF fragment identifiers in URIs are a lot more important than people are used to outside of this realm.

I'd settle even for a note above the examples which just explained why they're there, e.g.:

NOTE:

We use a fragment identifier (#me) in the examples below to distinguish between the description of the holder of the WebID (/foo#me) and the document which contains that description (/foo).

(Maybe with a link to more information about why this is important in a broader context?)

That way, there's no overt steer, but it does mean the choice is not completely opaque to the newcomer.

> I think there's a big need to explain 1-3 to a wider audience ... but maybe this is the job of the TAG / W3C / AWWW, rather than in this spec...

It's not really hard to explain given the right form of words, and I'm not sure devolving it 'upwards' is necessarily in anybody's interests — it seems to be to be akin to ducking the issue and hoping it will go away.

M.

--
Mo McRoberts - Technical Lead - The Space
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Monday, 18 February 2013 09:11:39 UTC