Hi All, Lets start moving on to the real work now. For any good specification we need some goals to test if it fits the use it is intended for. 1) a basis for a master format for PG 2) a basis for testing if a format can be used to mark up a book that is used and accepted by PG 3) a basis for a mark up language or needed features 4) a basis for what should be used to constrain the use of features in any given mark up language so that the file can be accepted by PG 5) a basis for building converters to the master format 6) should be able to capture the original layout of the book 7) should consider that it is to be used for creating derivative works in the output formats PG supports 8) should be strict! That is avoid having more than one way to mark up a feature. 9) will not based on any mark up language I think that wraps that up fairly, good. Did I miss anything? Of course I am assuming PG will adopt this in the end or at least sanction it as a best practice. So: 10) used by PG as a guide. regards Keith.
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
participants (2)
-
Joshua Hutchinson -
Keith J. Schultz