[DTownSMR]

I've re-worked this several times because I thought it might be taken as being argumentative, which I'm not trying to be. However, I'm not sure how well I did.     If you think it still does read that way, I'll apologize in advance because that's not my intent. I'm merely trying to convey a different POV. 

I'm actually not typing it in. I use a program to convert screen scrapes. I highlight the key, and press "Key" in the sidebar and it formats the data as a chordPro directive.

Correction: "as a custom, ChordPro-style, directive."

IMHO removing abbreviations, whose use seems to be pretty widespread, will not benefit the standard

The current standard does not have the "key" directive, nor any abbreviation for it. It's a new directive.

How far behind the standard is from the implementations and/or if and when it's going to catch up isn't really my concern. From my POV if the software I use to convert to chordPro format and all the software we use to display it on our iPads and Android tablets all have the same "custom, ChordPro-style, directive.", it's just a chordPro directive to me (however technically inaccurate that may be...today).

btw, many (if not all) of the implementations of readers that I've come across that support custom directives have also followed the standard and supported abbreviations for those custom directives.

The reason I encourage the use of full keywords is that abbreviations quickly become confusing. For example, {artist:...} and {album:...} are clear, but what is {a:...} ?

That's exactly the point of a standard. Would be to state what "a:..." means.

I would agree that full keywords is desirable for human readability but that's not my use case and I'm not even sure human readability should be a primary goal. Ideally, the chord chart would have no markup and the software would just be able to process it like we humans can. Since the markup is there so a computer can understand and they're not confused by abbreviations I'm not sure why it's a concern. Granted folks new to hand crafting chordPro directives will find human readable form useful but after 10 or so files they'll be very thankful for abbreviations. And if they're generated some other way there's no reason to care. Am I missing a use case?

My use case: I use a program to convert screen scrapped text to chordPro format at which time what it looks like is irrelevant and never again read by a human. From that point on it's only computer software parsing it to display and I'm pretty sure they won't get confused by abbreviations.  

Anyway, ChordPro is an advisory standard, everyone is free to implement it the way she sees fit. But I think we all benefit from trying to stick as close to the standard as possible, or convenient.

Certainly standards are only successful (i.e. a "standard) when they are followed however I think you'll actually find the reverse to be true when it comes to standards. The more restrictive or unaccommodating they are, the less they are embraced and/or followed. At least that's been my experience. And yes, I do realize "restrictive & unaccommodating" are VERY subjective but a reality none the less that we have to deal with.  

That program uses abbreviations and is out of my control.

Have you considered contacting the author?

Sure, and he's been very accommodating and I'm sure he will so again.

I also believe that when I initially switched to chordPro format MSP supported an abbreviation for key. I know for sure it didn't crash as it started to do when I started this thread. And although I can't go back and test it out now to know for sure, I do know that the current behavior is different enough that I believe I would have noticed that the key abbreviation wasn't working. As a software developer I consider this a regression bug (if I'm correct of course LOL). Moreover, it has the potential for future failure if I ever have to re-import those files again. They'll either crash MSP or silently fail...both are bad options over something as trivial as support for abbreviations.

Plus, I think the standard should be consistent. It started with supporting abbreviations, folks writing implementations also use abbreviations for both generation & consumption, and IMHO the standard should also support them in the future even for new features. I do understand that could cause potential conflicts where custom directives become official standard directive and different implementations may have used different abbreviations (like {a:...}). Hopefully those conflicts, or at least a majority of them, could be detected and handled by using letters in those abbreviations.

For what it's worth...YMMV