|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
|
|
[fileapi] urn -> URLI don't see a reason why we should call the member urn. URL is much more
consistent with other parts of the Web platform and works just as well. I thought we agreed on this previously so I'm just mentioning it here since it seems to have changed again. -- Anne van Kesteren http://annevankesteren.nl/ |
|
|
Re: [fileapi] urn -> URLAnne van Kesteren wrote:
> I don't see a reason why we should call the member urn. URL is much more > consistent with other parts of the Web platform and works just as well. > I thought we agreed on this previously so I'm just mentioning it here > since it seems to have changed again. "URN" seems to be fine as long the identifier actually *is* a URN (which it currently is). That being said, and as mentioned before, I'm still not convinced that the spec needs to recommend a specific URI scheme. We have talked about that before; is there something in the mailing list archives that actually summarizes why this is needed? Finally, *at this time* (while it *is* a URN) renaming to "URL" would be inconsistent with the relevant base specs, and produce even more confusion. The right thing to do here is to stay consistent with WebArch and RFC 3986, thus fix the terminology in HTML5. BR, Julian |
|
|
Re: [fileapi] urn -> URLOn Thu, 12 Nov 2009 07:45:30 +0100, Julian Reschke <julian.reschke@...>
wrote: > Anne van Kesteren wrote: >> I don't see a reason why we should call the member urn. URL is much >> more consistent with other parts of the Web platform and works just as >> well. I thought we agreed on this previously so I'm just mentioning it >> here since it seems to have changed again. > > "URN" seems to be fine as long the identifier actually *is* a URN (which > it currently is). > > That being said, and as mentioned before, I'm still not convinced that > the spec needs to recommend a specific URI scheme. We have talked about > that before; is there something in the mailing list archives that > actually summarizes why this is needed? > > Finally, *at this time* (while it *is* a URN) renaming to "URL" would be > inconsistent with the relevant base specs, and produce even more > confusion. The right thing to do here is to stay consistent with WebArch > and RFC 3986, thus fix the terminology in HTML5. It would however be consistent with WebSocket.URL, <input type="url">, url("image"), EventSource.URL, HTMLDocument.URL, etc. Keeping the author-facing APIs the same would be a good thing IMO. -- Anne van Kesteren http://annevankesteren.nl/ |
|
|
RE: [fileapi] urn -> URL> Anne van Kesteren wrote:
> It would however be consistent with WebSocket.URL, <input type="url">, > url("image"), EventSource.URL, HTMLDocument.URL, etc. Keeping the > author-facing APIs the same would be a good thing IMO. +1 I found the use of the URN scheme a little opaque and magical. -- Paul (psd) http://blog.whatfettle.com http://osmosoft.com |
| Free embeddable forum powered by Nabble | Forum Help |