[Cbor] Re: EDN redux

[Rohan Mahy <[e-mail]>]

Hi Carsten, since you think so many people misunderstand what this document
is for, maybe you could write your *requirements* so you're on the record.
They certainly seem to have shifted at various points in this argument.

I think the most important value of EDN is to provide a well-specified,
easy-to-use, JSON-like, human-readable and human-writable format that
end-users can use to express CBOR instance documents, and can be converted
in both directions.

Extending app-strings is pretty low on my list compared to any of the
above, and certainly makes any machine-consumable conversion to/from CBOR
instance docs more complicated. To be clear, CBOR didn't define tag 999.
This is yet another extra "feature" you've added to the EDN draft.

Thanks,
-rohan

On Wed, Aug 7, 2024 at 8:21 AM Carsten Bormann <[e-mail]> wrote:

> On 2024-08-07, at 17:07, Rohan Mahy <[e-mail]> wrote:
> >
> > Since you have gone so far as to propose no ABNF, a radically simple
> solution would be to not allow extensibility of app-strings. Define a set
> of them now and be done.
>
> I don’t think you understand what this document is about.
> Adding this extension point is the whole point of the draft.
> The ABNF is ancillary to that, but of course useful in its own right.
>
> The need for this extension point is rather native to the CBOR
> representation format, which has a related extension point in its “tags",
> and so far was missing a way to address the need for a notation for some of
> these extensions.
> (Getting the “tags" extension point accepted in 2013 was a bit of work,
> because nobody had done things quite like that before, so I’m having a
> little deja vu here.)
>
> I don’t understand how the convictions you have about the use of ABNF
> should prevent this rather natural addition to the CBOR ecosystem.
>
> The extension point is more important than the ABNF grammar.
> Also, the work on the ABNF grammar is done and can easily be used by
> implementers that want to base their implementations on ABNF.
> Still, removing the ABNF grammar would create a ton of editorial busywork,
> with significant editorial hazards, so I’d rather keep it in place.
>
> We are discussing the exposition of a feature (how exactly should ABNF be
> used in operating this extension point).  There is no argument at all that
> this exposition cannot be understood.  So I’d prefer if you gave up your
> concerns that are entirely foreign to the work at hand.
>
> Grüße, Carsten
>
>