Re: [web-nfc] local types need some prefix of a kind (#375)

We need to make a decision between

1. Use TNF and TYPE fields to identify NDEF records (low-level). Other NFC APIs use this (e.g. using both `tnf` and `type`) with this [mapping](https://w3c.github.io/web-nfc/#data-mapping).

2. Maintain the current mapping between TNF+TYPE to the [recordType](https://zolkis.github.io/web-nfc/#the-record-type-string) string, which is more webapi'sh, but creates a clash with possible local type namespace. That conflict could be resolved by:

    a) using a flag like `boolean local` to tell a record is of local type 

    b) prefixing algorithm for `recordType`, e.g. choose a prefix string like `"_"` or `"local:"` and add/remove it consistently. For instance, a local type written as `"text"` would be specified as `"_text"` or `"local:text"` in the API. A local type written as `"_text"` or `"local:text"` would be specified as `"__text"` or `"local:local:text"`, respectively.

So the problem is that we don't use the NFC Forum standardized type names in the API, but invented our own (which we thought were more convenient for web developers). However, the scope of the API has moved from high-level to low-level, so IMHO now it should be fine using the NFC Forum standardized type names.

My take: I am not convinced the arbitrary complexity introduced by Web NFC in 2b) is worth doing, for the sake of saving complexity of defining both (standardized, i.e. already known) TNF and TYPE by applications.

Therefore my vote goes either for 1) or 2a).


-- 
GitHub Notification of comment by zolkis
Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/375#issuecomment-568164890 using your GitHub account

Received on Saturday, 21 December 2019 08:55:11 UTC