I've not posted to the list before before and I've only seem a bit of traffic on here. I did see the article Barry wrote. Hopefully you won't mind me commenting on this. I apologise if I am going over "old ground", as if I am, I am unaware of that fact.
I think there is a problem with the approach outline below by John Walsh.
In many places you are taking an already existing tag (for want of a better word), such as X: or T: or t:, whatever and adding overrides with no prefix to indicate it is an override. For example, the CAPTION override for the T: field which currently indicates a text field describing the tune title.
T: CAPTION "my snippet"
What if a tune starts with the word CAPTION? Stranger things have happened.
ABC is easy to parse for humans, hard for computers, especially when dealing with hand edited ABC. I've just written an ABC parser and parsed 17000 odd ABC tunes - some of which had elements in the wrong order (according to the spec), daft mistakes, or were completely unparseable, even though a human could identify what to do with them. The unparseable ABC files were ones that people had typed free text into without using N: H: or % or quoting the text (*) as appropriate. They had intended to augment the file to make it more useable - but the result when loaded into ABC players was that the free text characters that matched musical notes turned into notes and the others matched the reserved lowercase/uppercase characters in ABC 1.7.6/2.0 and simply dissappeared. End result: No text, and music appeared that was not part of the tune.
(*) Seems that many packages will take "quoted text" as an additional title
When modifying ABC, although I agree with your ideas, please do it in a way that is straightforward to parse for machine consumption.
If the override, as I've called it, was prefixed (and postfixed) with a character not found in language, then that would make such overrides unambiguous. The postscript overrides use %% don't they? Or something similar, why not use a similar scheme (not using the same symbols as postscript).
T: [[abc]]CAPTION[[abc]] "my snippet"
Not the prettiest, hopefully my point is clear. Doesn't have to be as I suggest, I am just suggesting something less ambiguous. I'd quite like to see an XML style approach, as that is not ambiguous and has clearly defined markers and methods for adding unusual text.
T: <ABC>CAPTION</ABC> "my snippet"
Its very unlikely that a tune will start with the name <ABC>.
I've been writing software for 20 years odd, and ambiguous parsing is a nightmare. Please try and make extensions/modifications to ABC unambiguous.
Regarding the XML markup comment above, if ABC was marked up using some XML style language, I think it would reduce it machine readable only (which probably isn't what many people want). After all who wants to read
<NOTE base="A" accidental="sharp" length="2" octave="3" tie/>? :-)
Stephen
Since the t: field is designed for general information, usually unprinted, one could add a keyword, e.g. t: PRINT to indicate that the field is to be printed. One should be able to print extracts---one or two bars---as well as whole tunes. Extracts would have to be processed a bit differently from tunes, so perhaps one would want to add a keyword to the X: field: say X: EXTRACT, to indicate this. Since captions might be more important than titles, one could have, say, T: CAPTION <text> for that.
-- Stephen Kellett Object Media Limited http://www.objmedia.demon.co.uk RSI Information: http://www.objmedia.demon.co.uk/rsi.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
