Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126

[Christophe Lohr <[e-mail]>]

>>    3.  Data must be able to be decoded without a schema description.
>>        *  Similar to JSON, encoded data should be self-describing so
>>           that a generic decoder can be written.

My confusion comes probably from vocabulary issues.

The sentence here probably talks about "a schema description" from the
/coding-decoding/ point of view, and nothing else.

Such as, let's say, the IP header: without the RFC in hands (its
description), there is no way to decode a set of 20 bytes and to guess
that the first 4 bits are an unsigned int, followed by another 4 bits
unsigned int, followed by an array of 8 booleans, etc. 
A CBOR (or a JSON) coding format can tell this, without the need of
another writing document to specify this.

However, I read "schema description" from the /semantic/ point of view:
a description which explains the meaning of data items.  The IP RFC not
only tells that the first 4bits are an unsigned int, it also tells that
this number is the protocol version. 
CBOR (neither JSON) can't tells this by itself, except if one defines a
TAG for this.


So, the next question is: "is there some guidelines for using TAGs?"

Well, it's probably too early. One may have to wait that CBOR usages
grow in maturity.
But what's your opinion?

Let's say I'm designing a system.  CBOR is used (for messages, recording
data files, or whatever).
What should I decide for my system design regarding CBOR TAGs?
Shall I:
- prohibit TAGs since this is redundant with other parts of my design
specifications (which already explicit the meaning of each field); or
- put TAGs everywhere for everything because TAGs bring semantic to data; or
- add TAGs to some fields and not to others (which ones and why?)

The right answer is probably: "this depends". ;-)
but of what?

Best regards
Christophe