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

On Mon, Feb 18, 2013 at 10:03 AM, Mo McRoberts <Mo.McRoberts@bbc.co.uk>wrote:

>
> 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.
>

+1

That was the main reason why I added the note. While I agree with everyone
that most people would just copy/paste the examples, other people may want
to adapt their own user management system to accommodate WebID. Having a
(not the) note there would help them better understand the examples. It
really boils down to that.

Andrei


>
> > 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.
> -----------------------------
>
>