Eric, > For instance, in my recent org documents, I have added a #+calc: keyword > which I use for embedded calc lines. This allows me to have a clearly > labelled line that Calc will recognise and that I can process using a > filter before export while also ensuring that other tools, e.g. ones > which will ignore lines starting with #, do not fail. If the standard > did not allow for arbitrary keywords, would this limit my use?
perhaps the standard for e-mail headers (originally, RFC822) might be a useful way of thinking about this issue. it standardizes what it standardizes, and then says, "and, by the way, you can put in almost anything else [X-Mailer, ...], but you can't count on any other node understanding it". over time, new things are standardized (and, so, moved to, e.g., Mailer, and other things aren't. it seems to me this has worked fairly well, and partly this works because of the late Jon Postel's admonition for designing internet protocols: be conservative in what you send, and liberal in what you accept. [1] cheers, Greg [1] i.e., be extremely picky about sticking exactly to the letter of the standard in generating, e.g., documents, but allow for some sloppiness in the format of incoming documents.
