01-15-2016, 01:33 AM
(01-14-2016, 08:52 AM)sciurius Wrote: Jon Postel's robustness principle (a generally accepted design guideline for software) reads: "Be conservative in what you send, be liberal in what you accept".
Words to code by!
(01-14-2016, 08:52 AM)sciurius Wrote: Any program is completely free in accepting directives, abbreviations, whatever. Any program is completely free to accept "k" as an alternative way to specify the key of the song. But the ChordPro standard only defines "key". So programs are encouraged to use "key", but are free to accept "k" as well if they feel so. Do not think too easily that generated data is not meant for humans. Historic mistakes include PostScript, Forth, and XML.
Agreed, there very well maybe use cases where human readability is a concern. Are they the predominant/most frequent ones?!? I don't know. But what I do know (or at least think I know ) is that the standard would be best served by being as specific as possible. Harkens back to your Jon Postel quote. The more specific the standard is the less likely that implementations will be incompatible.
(01-14-2016, 08:52 AM)sciurius Wrote:Quote:That's exactly the point of a standard. Would be to state what "a:..." means.
Even if the standard did define a meaning, would you know it? At all times, without looking it up?
For example, I often use a id3 tagging tool that uses command line options -a for album and -A for artist. Or the other way around. Each time I have to lookup what means what.
On the other hand, the unabbreviated options are --artist and --album. Clear and unambiguous.
You lose nothing by generating unabbreviated keywords, but you may gain a lot.
I'm not suggesting that you do away with non-abbreviated directives so that someone that doesn't know has to look everything up. Merely that keeping the standard consistent by offering standard abbreviations across the board would benefit the standard and the community of users. You could (and probably should) still highlight that the recommended practice is to use non-abbreviated directives and state the reasons to avoid using abbreviations.
I did spend a little bit of time Googling & looking at some implementations. Of the ones I found, most that offer custom directives generally offer an abbreviation as well. My guess is since the standard has opened that can of worms (so to speak), it's become a general practice with implementers. Again, YMMV.
Samsung Note 10.1 GT-N8013ZW / iPad Pro / AirTurn BT-105 / AirTurn BT200S-4