Re: [File API] Recent Updates To Specification + Co-Editor

On 29.06.2010 20:40, Arun Ranganathan wrote:
> ...
>> I may sound like a broken record, but it's still not clear to me why
>> you need a custom URI scheme here. If you plan to actually register it
>> with IANA (you do, right?), you will have to explain why it's needed.
>
> Both you and I may sound like broken records, since we've definitely
> been down this road before :)

I know :-)

> I do plan to register it via IANA.
>
> Note that we started off with a URN scheme (urn:uuid). This was chosen
> initially to bypass a cycle with IANA, but this wasn't adequate. No
> browser implementation really uses URN schemes; they aren't used in web
> pages; implementers, including Firefox, cited a preference for URLs with

A URN is a URI. blob is a would-be URI as well. No web page uses "blob" 
right now, so I'm not sure what point you're trying to make.

> a scheme (for instance, nightly builds of Firefox use moz-filedata: as a
> scheme). Moreover, we wanted something that could be used in all places
> on the web platform that URLs are used today, including Web APIs like
> XMLHttpRequest, and for elements (like <img src..>). Lastly, while a URN
> scheme could have been used with an attribute called URL, that seemed
> wrong.

I don't see why you can't do these things with urn:uuid:.

> We have file URIs ("file://") on the web platform today, and some
> implementations actually support use such as that mentioned above. But a
> scheme that referred to individual Blobs or Files that could be used
> with response codes was the best course of action (with no path, etc.).

All true & understood; but I still don't see why this needs a new URI 
scheme.

> ...
>> - How do you guarantee uniqueness if opaqueString is free form? Is
>> this just "unique per producer"? Are you sure that never ever two blob
>> URIs from different producers will get into the same context? If
>> you're sure about that, why do you need a URI scheme in the first place?
>
> It is likely to be unique per producer. In fact, Chrome folks may wish
> to use origin tokens in the URI scheme, and even if they didn't, the use
> of UUID would result in differences per producer. If by different
> producers, you mean that a Blob URI coined by Chrome may have no meaning
> in Firefox, you're likely to be right.

So if a blob URI produced by Firefox leaks into Chrome, what happens? If 
this *can* happen, you may need to require more than per-producer 
uniqueness.

> While the *format* that the URI takes may vary per producer, it seems
> wise to at least define a scheme that can be used commonly by user
> agents. Authors may never interact with the URI itself, but only with
> the Blob.url property -- that is true. But at least a scheme gets us
> something that's better than total arbitrariness. Do you disagree
> strongly? I also think that leaving things undefined isn't desirable in
> general.

I actually do not see what benefit this scheme brings.

>> - You don't need to make statements about fragment identifiers; they
>> are not part of the URI scheme itself
>>
>
> That's right. I want to emphasize that they are allowed. I took this
> from the RFC on WWW URIs, cited in the text. Maybe I can add a
> non-normative section on the use of fragment identifiers? Is that your
> suggestion?

The semantics of fragment identifiers follow from RFC 3986, Section 3.5 
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>) and 
the media type that is being retrieved. So normative statements would be 
incorrect, but explaining what's going on wouldn't hurt.

>> - That being said, if you do you should point out how they work (do
>> they depend on the media type of a representation?)
>>
>
> Right -- I do in the spec. They depend entirely on the media type of a
> Blob. Is the existing text insufficient?

I didn't see it. Most is accurate. I'd rephrase

"This scheme can allow for fragment identifiers for well-defined format 
types...."

though. The scheme can't allow or disallow anything; it really only 
depends on the media types of the representations you get upon deref.

 > ...

Best regards, Julian

Received on Tuesday, 29 June 2010 19:27:52 UTC