AltME: Ren - Data Exchange Format

Messages

Gregg
What is the strongest argument against a spec of:
    opt sign  int ":" int ":" int opt frac
whether as just time or part of date-time?
This is just how data is exchanged, perhaps with suggestions for useful, standardized semantics.
Geomol
I would allow this also:
    opt sign int ":" int
meaning hour:minute. Some systems don't care about the seconds, and the format will be bloated, if that's the case.
Gregg
My spec does that currently, but it is potentially ambiguous. Just looking at data, you don't know if it's hh:mm or mm:ss. Not sure requiring :ss qualifies as bloat. :-)
The biggest reason I support opt seconds is for REBOL compatibility. It is convenient.
Geomol
Yes, convenient, and I think also easier to read for those, who never operate with seconds. "Meeting at eleven hundred."
Users of the format just have to know, it's always hours:minutes in such cases.
Gregg
Right, the spec being:
    opt sign hours-minutes opt seconds
Rebolek
Actually, I'm never sure if 10:20 in Rebol is HH:MM or MM:SS.
Geomol
About my point regarding bloat, I do mean it. :) Figure a system with thousands of hour:minute data being exchanged. If you force seconds in, which will always be 00 in such a system, and it will look like XML with end-tags. It is unnecessary bloat.
If you use Ren to exchange data between systems, where it means MM:SS, and you allow the first part to be any value (larger than 23 also), then it should work too, shouldn't it?
Isn't Ren about what you allow users to write. How they interpret it, is up to each case.
A string in one human language might mean something else in another human language, but it's still valid text.
Gregg
It's an interesting problem, because whether hh:mm or mm:ss is expected is based on context. The only way around that is to require all fields. Of course, REBOL made a good call, and it's right most of the time, but I've been tripped up by it a couple times myself. More importantly, you have to explain it to everyone that needs to use it. hh:mm:ss is unambiguous.
But if it can be either, and we only allow decimals on seconds, it gets trickier still.
Geomol
In a language with computation, you need to explain, yes. But in a data format, couldn't you let it be up to the user, how to interpret two integers separated by a colon?
The argument to mee is like sending just one integer telling the receiver, it's the number of days until some event. If the receiver choose to interpret the integer being number of weeks, we have a problem. But I wouldn't restrict the format because of just misinterpretation.
mee -> me
Gregg
My point about context, yes. BUT (all caps), what does your spec look like now? Ugly is what.
Geomol
:)
Date and time is some of the hardest datatypes to implement.
Rebolek
I think the REN data format should be self-explaining. XX:YY isn't.
Gregg
Now we know why JSON left out date-time. :-)
If we make seconds optional, the onus is on the user to make things unambiguous if they want. If we say two segments are hh:mm, that's what they are, even if we sometimes forget. :-\

Last message posted 408 weeks ago.