Hi Joshua, First off, sorry to everybody for my typo should be ANA. I do not why type APA, maybe it sounds better. No I am not reinventing the wheel or suggesting a new mark up. I am trying to develop a feature set that can be used to constrain existing mark up languages or used if one wishes create another. You see, for example, not all HTML works on all reader devices. So we have to guide the contributors to avoid certain features. ANA can help here. Also, ANA can be applied to RST to see if it contains enough features for adequately producing ebooks. Furthermore ANA could be used to check the CSS involved. Or ANA could be used on zml. Maybe, it could use a feature. Also, IF the mark up files of the contributors conformed to ANA it would be very easy to make converters so no matter what "master format" or output format is used there is a defined feature set which can be mapped. ANA is to be a specification. It is not to be technical. It will not say you have to use \chapter as the syntax. Yet, if you conform to it the person(implementors) will know that they have to have some way of identify it in their pet mark up language. Such a specification will help developers know what to expect, and figure out ways how to constrain/convert input from one input to another! You might say this is not a specification, but it is. It is simply this stage of the specification process hardly even makes it into the publish specification in this form. regards Keith. Am 08.02.2012 um 00:46 schrieb Joshua Hutchinson:
Why #9? Curious why we *must* re-invent the wheel. I'm not saying it should be avoided, but I'd rather stand on the shoulders of giants.
Josh
On Feb 6, 2012, Keith J. Schultz <schultzk@uni-trier.de> wrote:
9) will not based on any mark up language
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d