- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Aug 2015 12:59:14 +0000
- To: public-web-nfc@w3.org
@domenic > The { type, data } seems a bit better to give a more direct mapping to NFC (although in that case just exposing TNF and MIME type would be more appropriate). There is some overlap in NFC regarding TNF and MIME types vs mappable JS types, so for *Web* NFC we have already done a slight mapping [here](http://w3c.github.io/web-nfc/index.html#web-nfc-payload). Then, we didn't mean exposing the low level NFC details in this spec - for that we still have the older WG spec which follows low level details very well. This spec is more like "rethinking NFC usage for the Web", and the argument would favor @annevk 's design (indeed we have iterated through a similar design with @kenchris earlier). I'd rather start with ``` enum NFCDataType { "url", "string", "json", "blob" }; interface NFCData { readonly attribute NFCDataType type; Blob blob(); JSON json(); // same as 'Object json();' USVString url(); DOMString text(); // ArrayBuffer arrayBuffer(); // skip this if we don't expose the low level content } ``` since in that case we have some indication how the content should be handled by the client. Functions may throw type exceptions. But I might miss the details behind the ```"opaque"``` type idea. Thank you all for helping in this. -- GitHub Notif of comment by zolkis See https://github.com/w3c/web-nfc/issues/26#issuecomment-129862210
Received on Tuesday, 11 August 2015 12:59:16 UTC