On Wed, Sep 9, 2009 at 10:17 AM, Robin Berjon<[email protected]> 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.
