Prefixing local records with ":" would be simpler than isLocal

[kenchris]

I don't like isLocal because its optional so easy to get wrong, which is made clear with the last commits "sprinking it" over existing code :)

":" is not a valid first character for local record types, so it is fine.

I think it makes sense because we have local records in namespaced (external records) or standardized records (smart poster). It looks like a namespace where you just didn't explicitly write it out.

It will make make it very explicit where a local record type is used.

const writer = new NDEFWriter();
writer.push({ records: [
  {
    recordType: "imdb.com:movies",
    data: { records: [
      {
        recordType: ":rating",
        data: 10
      },
      {
        recordType: ":title", 
        data: "Rise of Skywalker"
      }]
   }
}]);

[kenchris]

a recordType: "text" would thus be a normal T record, and recordType: ":text" would be a local record of type "text"

[beaufortfrancois]

FYI @kenchris #375 (comment) explains why the prefix idea was not picked.

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.

[kenchris]

A local type written as "_text" or "local:text" would be specified as "__text" or "local:local:text", respectively.

_ and : are not allowed as first letter in local types, has to be number or lowercase letter, so you would never run into the above issues

[beaufortfrancois]

For the exercise, I've updated spec to see how it would look: #502

[zolkis]

Right, I have overlooked that : is illegal starting character for local types.

However, developers might be confused with this new Web NFC specific convention. It is also confusing because : is a separator in external types.

On the other hand, in a way it's a logical choice (local is like external, just that instead of the explicit domain-context we have the implicit local context).

I'd prefer using the NFC Forum standardized type names, but we could assume this as a working hypothesis.

We should make Notes about the Web NFC introduced conventions about type names and ask for developer feedback between this (the current way) or using the plain NFC Forum standardized type names (T, U, Sp, act, etc).

[beaufortfrancois]

#502 has been merged.
#504 has been opened to track which differences we want to highlight about Web NFC vs NFC Forum spec.
@kenchris Please close this issue at your discretion.