Re: Fragment Identifiers and Agent Perspectives

On Tue, Oct 11, 2011 at 11:39 AM, ashok malhotra
<ashok.malhotra@oracle.com> wrote:
> Jonathan:
> I agree that we cannot/should not try to update 3986.
> So, we should write a separate document clarifying frag id semantics and
> usage.
> But form should this document take?  W3C Note, TAG Finding?

That would depend on what would best serve the constituency;
unfortunately the constituency is sort of elusive. Maybe we should
consider merging this with the httpRange-14 / issue-57 work, which we
agreed was supposed to go on rec track (Architectural Recommendation).

> You said "Just for the record I don't particularly like Manu's suggestion,
> ..."
> Not sure what you are disagreeing with.  The idea to amend 3986 or the
> content of the message we want to send.

The idea of having one URI "identify" two different things. If this is
forced somehow, I'm OK with it, but I don't think we've played it out
fully. E.g. is there any prospect of getting the browsers to treat
@about similarly to @id? That would remove the pressure to use one
fragid in two incompatible ways.

> This issue has been kicking around for a long time.  Perhaps we could
> discuss
> on Thursday and find a way forward.
> All the best, Ashok

Sure.

> On 10/11/2011 7:58 AM, Jonathan Rees wrote:
>>
>> I'm finding the indented response form unwieldy, just wanted to
>> contribute a few points in reaction to various previous messages:
>>
>> - The discussion of 3986 derives from my saying the following to Manu:
>> "Might need a revision to RFC 3986." I didn't say anything about who
>> would do it. And those who know me know that I often drop outrageous
>> suggestions just to get a reaction or make a point. It's clear that
>> revising 3986 is almost certainly infeasible, and I meant it as much
>> to push back on Manu's suggestion as anything else.
>>
>> Happily, Roy and Martin have clarified that it will not be necessary
>> to update 3986. 3986 is so unclear, by design, that it would be hard
>> to write a document addressing these issues that contradicted it.
>> Therefore I suggest we drop the idea of revving 3986, except maybe as
>> a thought experiment. Instead the focus should be on amending it
>> externally, in the same way that AWWW did.
>>
>> - Manu says he can't point developers at a document that answers the
>> questions that developers have. I absolutely agree. I think the TAG
>> could produce or supervise such a document, but it's been difficult to
>> find the manpower and determination needed to create it (it's
>> essentially the same as the httpRange-14 work I've been struggling
>> with). If anyone has any new ideas on how to advance this project let
>> me know.
>>
>> - Just for the record I don't particularly like Manu's suggestion, and
>> I would want to look hard for alternatives; but I wanted to make sure
>> that the idea was written down and discussed here. My sense is that
>> it's hard to keep those affected by the TAG's issues in dialog with us
>> and I appreciate that Manu spoke up.
>>
>> Jonathan

Received on Tuesday, 11 October 2011 16:00:26 UTC