[web-nfc] Handling NDEFRecord (#510)

zolkis has just created a new issue for https://github.com/w3c/web-nfc:

== Handling NDEFRecord ==
@sleevi notes [here]():

> The only other bit I would flag, and I fully admit I'm not an expert here and so you'll want to find someone better versed in the Web Platform idioms, is where/how an error should be signaled for an unsupported recordType. Right now, if I understand correctly, I can create a 'valid' NDEFRecord via NDEFRecordInit, but whose recordType is invalid/unparsable. That error is not actually signaled back to the consumer until they try NDEFWriter.push, which invokes the create NDEF message algorithm, which invokes create NDEF record, which invokes validate external type.
>
> Because you expose the constructor for NDEFRecord, should you be parsing/validating the type then? The URL class, for better or worse, has setters which do the parsing/validation. I'm not sure why the NDEFRecord type is read-only (maybe that's the current best practice), but it seems that you at least want to validate during that constructor as well, to ensure a client only encounters well-formed NDEFRecords

In principle we create [NDEFRecord](https://w3c.github.io/web-nfc/#the-ndefrecord-interface) only when reading and we use [NDEFRecordInit](https://w3c.github.io/web-nfc/#dom-ndefrecordinit) in [push()](https://w3c.github.io/web-nfc/#the-push-method).

However, you are right that clients could just construct an `NDEFRecord` and that may warrant validation. Not that there is much they could do with them, since push will treat them as `NDEFRecordInit`and will create a new `NDEFRecord` out of them before pushing. 

@kenchris @beaufortfrancois please advise.

Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/510 using your GitHub account

Received on Friday, 3 January 2020 10:35:00 UTC