I think SimonM's suggestion of an RFC2822-like syntax is reasonable, but it
[my suggestion, not SimonM's!]
would probably be better to not simply cite RFC2822, since some
I agree, we should give an explicit definition. I don't think it's likely to be very complicated.
complications might arise. An alternative might be XML, which would be a more "modern" choice.
Ugh! No! Please! No! No reason to do this - remember, this file is written by Angela Author, who has just written a Haskell module or two, and doesn't have a handly XML structured editor to hand. She just wants to fire up her text editor and write three lines.
Some nits to look out for with RFC2822 format are: + Internationalization and non-ASCII characters
We should specify either Latin-1 or Unicode/UTF-8. The latter, I guess.
+ Case (in)sensitivity of header field names
Insensitive would follow the Principle of Least Surprise.
+ No support for structured information (text string values only). + No facility for grouping information + Comments in some header field values
I was imagining that the text string would almost always be a Haskell value, using the Haskell lexer and a Haskell-related parser. This would give us comments and structure.
+ Extensibility model
Yes, this should be specified. The document already implies "ignore headers you don't understand", which is good.
I think it would be good to include a commenting convention. (Use Haskell conventions -- and {- ... -} ?)
See above.
Keep up the good work!
:-) Try this, using the Haskell Report grammar syntax, and Section 2.2 of the Haskell Report for the definitions of <lexeme>, <newline>, and <whitespace>: <description> ::= { <descline> } <descline> ::= <fieldname> : { <lexeme> | <foldedwhitespace> } <newline> <foldedwhitespace> ::= <whitespace> | <newline> <whitespace> with the proviso that any <newline> in <foldedwhitespace> has no semantic significance. Alternatively, we could provide Haskell code as specification here. --KW 8-)