- From: Mark Baker <distobj@acm.org>
- Date: Wed, 9 Sep 2009 13:01:42 -0400
- To: Robin Berjon <robin@berjon.com>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Sep 9, 2009 at 10:17 AM, Robin Berjon<robin@berjon.com> wrote:
> On Sep 8, 2009, at 17:18 , Mark Baker wrote:
>>>
>>> function getSection () {
>>> return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
>>> "$1").toLowerCase();
>>> }
>>>
>>> I won't say that it's necessarily the best-written code, but it's not
>>> daft
>>> enough to be shrugged off and it's not particularly contrived. It's easy
>>> to
>>> come up with a bunch of similar cases. If you get one implementation with
>>> more market-share than the others, then they'll have to copy its
>>> behaviour,
>>> and we'll then have to specify it.
>>
>> The regex could just as easily have been written to exclude the
>> authority component of the URI. Do you have a better example?
>
> It could have, but it wasn't — interoperability isn't what happens when
> people write to a W3C working group to get their code debugged, it's what
> happens when real people write code on their own.
Sure, some people will write really bad code. I just don't think we
have to accommodate all of them.
> Let us assume that we don't at all say what is returned by the many
> attributes that normally expose URIs. What regex would you "just as easily
> have written" to match an unspecified value? Here are some samples from
> several implementations given an image linked to as /img/dahüt.svg:
>
> A: http://magic.local/img/dahüt.svg
> B: file://mushroom.local/img/dahüt.svg
> C: file:///img/dahüt.svg
> D: file:///C|/img/dahüt.svg
> E: \\myphone\img\dahüt.svg
> F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY WIDGETS\MY
> ARSE\DAH~1.VML
> G: http:///img/dah%FCt.svg
> H: cool-product:/img/dah%u0055%u0308t.svg
> I: inode:DEADBABEC0EDBEEF
> J: many more things...
Some of those aren't URIs, and some aren't hierarchical. Of the
others, "[:/]//?*/(.*$)" should cover it.
But if it would simplify things, I wouldn't be averse to a getBaseURI() call.
> Another situation is a security manager that applies different policies
> based on scheme, authority, etc. URIs are useful — they can identify and
> locate stuff.
>
> Let's imagine we say nothing and you're an implementer: what would you do?
> Everyone in this discussion understands that introducing new schemes should
> be done with caution — what I don't understand is what architectural value
> you are seeing in not using URIs to identify resources, encouraging
> non-interoperable solutions, or sweeping the issue under the rug by
> delegating to a special name instead of a scheme.
I'm not doing any of those things AFAICT. I encourage resources to be
identified by URIs. I just don't see a need to tell implementations
what their URIs should look like, other than to say they should be
hierarchical for obvious reasons.
> We have a semantics that match no existing scheme. We have a locator
> behaviour that matches no existing scheme.
The identifiers produced by implementations you list above suggests
that at least some implementors feel that they can reuse existing
schemes, no?
Mark.
Received on Wednesday, 9 September 2009 17:02:24 UTC