On Sat, Apr 9, 2011 at 3:12 AM, Sylvester Keil <[email protected]> wrote: > -----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.).
I've added the start of the schema: <https://github.com/citation-style-language/schema/commit/b98aecf31577eb8c188e57c56d381332a2f58881> I mostly focused on the getting the basic RNC structure right, with details still to be worked to be worked out. For example, apropos the last point, do we want to constrain the tag values? I have a few comments in the source to indicate other questions. Feel free to comment on the commit, or fork and hack. Bruce ------------------------------------------------------------------------------ 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
