-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 8, 2011, at 2:50 PM, Bruce D'Arcus wrote: > On Thu, Apr 7, 2011 at 8:39 AM, Frank Bennett <[email protected]> wrote: >> On Thu, Apr 7, 2011 at 9:28 PM, Bruce D'Arcus <[email protected]> wrote: >>> On the test suite itself ... >>> >>> On Thu, Apr 7, 2011 at 3:40 AM, Frank Bennett <[email protected]> wrote: >>> >>> ... >>> >>>> The "syntax" of the test fixtures is admittedly a dog's breakfast >>>> currently, set up in a rush before speeding forward with the coding. >>>> JSON has been used to describe the input data mostly because it does >>>> not require conversion (saving me the time required to write a >>>> converter), and because typing hundreds of tests in JSON by hand is at >>>> least a little less painful than writing hundreds of tests in XML. >>>> However, now that we have the processor running in at least two >>>> interactive applications, recasting the fixtures in a single uniform >>>> syntax seems a good idea, and the obvious choice would be XML. >>> >>> Two things: >>> >>> 1) are you suggesting re-casting the JSON input data as well in this >>> context as XML, or simply embedding the JSON in an XML node? I presume >>> the latter. >> >> It could be either. I had the former in mind, but I suppose the latter >> could be a whole lot simpler to code, now that you mention it. Once >> converted from my junkyard file format to something more standard, the >> content could be refactored to taste. > > We could start with: > > <data type="json"></data> > > In any case, what do we need? > > <test mode="citation"> > <style/> > <data type="json"></data> > <result> > <expected/> > <actual/> > </result> > </test> > > That work? > > Anything else? Off the top of my head: An optional <input> akin to the 'citation items' or 'bibsection' in the current test suite (if no input is specified, all the elements in <data> are to be processed). The <style> tag should support inline styles as well as URIs to load a certain predefined style (because styles can change that is not ideal for processor testing, but it makes writing the tests easier and is useful for style testing --- that way we can use the same test format for testing processors and styles. An optional <locale> tag outside of the <style> definition. Again, this should support inline definition or definition by reference. An optional <description> tag. An optional <tag> tag (or similar); this is something I find quite useful in cucumber: you can add any number of tags to a scenario description. For example, the tags 'experimental', 'v1.0', 'edtf', or 'html' could denote that the test is experimental, expected to work in CSL 1.0, uses EDTF input data, or formats the expected result in HTML). Tags are easily extensible, optional as they don't alter the test itself, but useful for filtering (e.g., I want to run tests that are tagged 'v1.0' but not 'v1.1' etc.). Sylvester -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2gBtMACgkQh4kzvOqyWhBsLwCeKCe7fackuLMy42nHGg9DHWet WRYAn0mMOgBGZKh0HppcBSlmZ4DX8A+A =yf3a -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
