Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate)

[Ujjwal Sharma <[e-mail]>]

Hey Ned!

On 01/06/2021 22.13, [e-mail] wrote:
> The main problem is that the charter specifies that a variant of RFC 3339 is to
> be embedded in this new specification, with no consideration given to the
> alternate approach of incorporating either RFC 3339 or an RFC 3339bis by
> reference.

The draft is the way it is right now because the original idea was to
obsolete RFC 3339 in favor of it, and I haven't managed to set apart
enough time to properly update it.

> This really isn't the time or place to get into all of the reasons why
> incorporation by reference is a much better way to do this, so I'll simply note
> that even if you ignore the confusion this can cause, having text in two places
> that describes the same thing has proved to be a maintenance nightmare on many
> previous occasions.

I don't have any opinions on the matter, but I agree with the principle.

> At an absolute minimum the choice of reference versus embedding should be left
> to the working group, rather than being effectively chosen by the charter, and
> this needs to be made very clear from the outset.

Right, I suppose we should change the charter... Is there someone who
strongly feels that the charter *should* mandate this?

> The charter also says that:
> 
>>     It is anticipated that this document would be a companion to RFC3339 rather
>>     than a replacement, embedding an unaltered RFC3339 instant along with the
>>     contextual data.
> 
> Except the current draft cited as a "good basis" for this work doesn't actually
> do this. Rather, it preemptively extends RFC 3339 in not one but two ways:
> 
> (1) Years are extended to six digits
> (2) Local offsets are extended to allow seconds and fractions of seconds.

I think your comment here highlights how the charter might be a tad
inconsistent with itself since above we talked about "a variant" of RFC
3339 being acceptable.

Talking more specifically about the two changes here, they were done
just to reflect the changes that have landed in ISO 8601 over the last
couple of years.

ECMA TC39 used ISO 8601 as the basis and added the extensions on top of
it, so I snuck these two changes in to make the final result consistent.
That said, I'd be fine to drop them if needed (or make a second draft
that does replace RFC 3339 and *just* has these two changes which we
could then reference in the draft with the extensions).

> Another problem is that the current draft makes a number of unnecessary changes
> to the RFC 3339 ABNF, e.g., full-time becomes time-full, full-date becomes
> date-full, date-fullyear becomes date-year, etc. Even granting that the new
> names are in some sense "better", the problem is that other specifications can
> and do reference specific rules in specifications like RFC 3339, and when you
> change the the rule names, you complicate the update process for all of these
> RFCs.

This is just feedback for the draft, nothing to do with the charter. As
I mentioned previously, the original idea was to obsolete RFC 3339 and
also nobody else raised this concern before. I would be happy to revert
to the old ABNF, which would especially make sense if we split the draft
into two, one obsoleting RFC 3339 and the other referencing the former.

> Finally, I concur with Carsten Bormann's point about noting that this is
> exclusively a *text* format for date time values. Simply inserting the word
> "text" in a couple of places would sufficient. And FWIW, I don't think extending
> the current charter to cover binary formats is a good idea. If such a thing is
> to be done, it should be accomplished via a recharter.

I agree that binary formats are out of scope here. I'd be happy if the
charter were updated to reflect that.

Hope I've managed to address your concerns,
Best,
Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker