I never thought time! would raise so many questions.
PeterWood
One way to distinguish between a time! and a duration would be that a time would need a timezone.
03:00 could be considered ambiguous as a time without a timezone. A duration is indpendent of timezone.
PeterWood
The counter argument would be a use case, where you wish to distrubute a time of day independent of timezone e.g the time of a nightly back up being 02:00
Geomol
time-of-day is a subset of a time! value. So defining time!, where hours can be > 23, and the format can cope with time-of-day. Is it up to the format the put restrictions in this case? Isn't it up to the user of the format to assure, hours <= 23, if it's a time-of-day value? And putting time from a date value in Rebol/Red/World/what-ever-language into REN will just work, and no checking is needed.
Gregg
Right. For example, JSON says what a number looks like but doesn't specify limits on number of digits.
The case of date-time values is a little tricker. Should Ren allow you to specify an invalid time of day? If so, behavior may vary by implementation (unless we provide guidelines). If not, the spec becomes more complex.
PeterWood
I feel that the REN standard should be specific and that a time associated with a date needs to be valid. Implementations may differ. After all, browsers have always rendered "invalid" HTML, libraries handle "invalid" XML and, to a lesser extent, libraries handle "invalid" JSON (even eval() can if some circumstances).
Gregg
Consider http://www.ietf.org/rfc/rfc3339.txt . The ABNF for hours is: time-hour = 2DIGIT ; 00-24 But also refs ISO8601 in 3339, where it says time-hour = 2DIGIT ; 00-23
The text says this: "Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion."
One of the things I want to do is provide a grammar for Ren, to bootstrap implementations and reduce confusion. Is it OK to have a simple informative grammar in the intro, which hides details, and a strict grammar for the real deal? Or is that "bait and switch" (luring people in with false advertising)?
And will a more complex grammar and stricter spec scare people off, or be worth it in the long run, for consistency?
Gregg
Or can we safely say the informative grammar *defines* the normative rules, even if the BNF cheats a bit, like 3339? That is, are we allowed to strictly say that hours in date-time MUST be 00-23, but the reference BNF says 2DIGIT to keep it simpler?
PeterWood
I think unambiguous, concise and simple win everytime when it comes to specs. People seem to spend hours (if not days) arguing over an ambiguity I can just imagine the arguments "the time in a date cannot be 25!" "Yes it can the BNF only specifies 2DIGIT).
PeterWood
In terms of simplicity, wouldn't syntax diagrams, as used by Douglas Crockford, be a good alternative to a BNF?
While I've stated my position before on what I see as the follies of separation of Ren from the Rebol format (a topic for another time, another day), I still have an interest in the formalisation of the Rebol/Ren/Red format and am eager to share any efforts I produce to this end. As such, I'd also like express disappointment that there is a whole body of discussion on this topic in a closed space (AltMe) that is ornery to access with no public reflection. It's not my wish to open another [web-public] debate, rather just a request to reconsider this place as the main repository of thought on the formulisation of the Ren format (if indeed this is Ren HQ). Looking here and on SO Chat, I see two discussions that seem oblivious to the ideas of the other (and no, SO Chat would not be my preferred choice either).
Chris
'will a more complex grammar and stricter spec scare people off[?]' I'm of the opinion that it's better to get as close as possible to a precise spec. It'll lack the concise representation that JSON has, but then it's never going to beat JSON for brevity anyway. Ever.
I agree a central place to chat would be great, but I don't find SO effective either. Do you have another suggestion? And who else wants to take part that finds altme ornery to access? My intent is not to be private, but to make the best use of my time.
Good point on never beating JSON for brevity. The hard part is not knowing how far out to push before we hit a point that turns people away.
We all seem to agree that specific is good. Unfortunately, specifically "what", WRT time for example.