Re: [web-nfc] URL objects

> I am just afraid that regular developers don't really know the mime 
type of, say URL. Should we use text/uri-list ? or text/x-uri ? or ...

I am not sure your mental model here. For reading, it will be 
perfectly obvious to developers that `{ type: "text/uri-list", data: 
"https://example.com" }` is a URL. (Although the crappy "URI" name is 
unfortunate.) For writing, I doubt developers are going to guess at 
the type they should use---they'll almost certainly look at docs or 
the spec anyway. So I don't think this is an issue.

> If we want to proceed with including simplified helper types, and 
don't want to lose type information, we need to use a variant of 
Anne's earlier proposal, something like this:

This proposal sounds good to me. Although, reading further, I guess 
not to implementers?

> Do we prefer mime instead of mimeType? Any existing examples in the 
web platform? 

I have been investigating this for a different spec, and so far 
everything I've seen in public APIs has been `type`.

---

> ```
>     USVString type;  // "url", "text", json", "opaque", or a MIME 
type
> ```

If we can't have kind + type, then I really don't see any value in 
this over just using a MIME type directly and only. The mapping would 
be:

- Writing:
  - text: authors supply `"text/*"` and data `"any text"`. Convert 
data to a string using usual Web IDL/ECMAScript ToString conversion.
  - URLs: authors supply `"text/uri-list"` (ugh) and data 
`"http://valid.url"`. Convert data to a string, then validate that 
it's a valid absolute URL; throw if it's not.
  - JSON: authors supply `"application/json"` or 
`"application/*+json"`. `JSON.stringify` the supplied value (throw if 
that fails).
  - anything else: authors supply any other non-special mime type plus
 a BufferSource (= ArrayBuffer or typed array). Any other type throws.
- Reading
  - TNF=1 Type Text => `"text/plain"`, deserialize to DOMString
  - TNF=1 Type URI, TNF=1 Type Smart Poster, and TNF=3 Absolute URI =>
 `"text/uri-list"`, deserialize to USVString
  - TNF=2 mime type `"application/json"` or `"application/*+json"`, 
`JSON.parse` it (throw if can't be parsed)
  - everything else => mime type as-is, deserialize to ArrayBuffer.

---

All this said I am not an expert and appreciate you guys are doing 
some hard work to try to map something that is not web-friendly to 
something that is. My gut instinct would be to expose things on the 
lowest level possible and then leave the nice web-friendly stuff for 
later specs or for author libraries, but I understand the effort to do
 something nicer and will trust you all to do so. I think everyone is 
on the same page about not using actual URL objects, which was our 
main concern, and at this point we're all just kind of throwing in 
ideas as to what seems like a nice API.

-- 
GitHub Notif of comment by domenic
See https://github.com/w3c/web-nfc/issues/26#issuecomment-130363562

Received on Wednesday, 12 August 2015 16:32:21 UTC