- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Oct 2019 07:06:34 +0000
- To: public-web-nfc@w3.org
One more point (sorry for the flood). As NDEF records are stored flat in an NDEFMessage and the payload length field is used to determine where a given record/message ends, it's a tree and not an array. Implementations need to parse the entire message to determine that record tree. In the current API we allow only smart records to be parsed into records in [9.4. Data Mapping](https://w3c.github.io/web-nfc/#data-mapping). Actually that could have a `records` property that should be non-empty. But then how should `records` work with other record types? When a record doesn't have NDEFMessage as payload, then it's trivial, however, a bit messing with the `toText()`, `toJSON()` and `toArrayBuffer()` helpers. The problem (again) is with external and unknown records. They will also have a `records` property, but it's not at all sure (actually is unlikely) they will have an NDEFMessage as payload. Now what should implementations do? Attempt parsing the payload as a message, just in case, that will fail most of the time? To me it seems way simpler to just have a `toRecords()` method that may fail. For the record, `toRecords()` is not my baby, IIRC it's Kenneth's FWIW, I just see it as good design. -- GitHub Notification of comment by zolkis Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/362#issuecomment-538272518 using your GitHub account
Received on Friday, 4 October 2019 07:06:35 UTC