Re: [fileapi] urn -> URL
12.11.2009, в 0:13, Anne van Kesteren написал(а):
It would however be consistent with WebSocket.URL, type="url">, url("image"), EventSource.URL, HTMLDocument.URL, etc.
Keeping the author-facing APIs the same would be a good thing IMO.
EventSource.URL and WebSocket.URL have been renamed in the relevant
specs to lower case since this discussion, which I think is unfortunate.
1. This doesn't buy us a lot of consistency, since document.URL is
likely the most familiar of these APIs to many Web developers, and
WebSocket/EventSource now use a different case for URL.
2. As we're trying to add consistency, we should take a path that
makes us consistent with what's available on Document. One way to do
that would be to support both url and URL in some interfaces.
WebSocket, Blob and EventSource can support both URL and url if really
necessary, but adding a "url" property to documents is likely to cause
compatibility issues.
3. WebSocket.URL and EventSource.URL are already supported in shipping
implementations. I think that there should be better reasons to change
shipping APIs than we seemed to have had here.
4. Blob.url isn't shipping with any browser yet, as far as I can tell
(Firefox 3.6.3 and Opera 10.54 don't have window.Blob; WebKit has it,
but doesn't have Blob.url).
I think that WebSocket.URL and EventSource.URL should be changed back
to upper case, and Blob should use upper case, too.
- WBR, Alexey Proskuryakov
RE: [fileapi] urn -> URL
> Anne van Kesteren wrote:
> It would however be consistent with WebSocket.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
Re: [fileapi] urn -> URL
On Thu, 12 Nov 2009 07:45:30 +0100, 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, ,
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: 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
