tests, input [was Time frame for completion of CSL 1.0?]

Hi Andrea; good to hear from you.

I don’t think we’ve set a revised target for the completion of CSL 1.0.

Shall we do that?

Just to let you know that I started working on the Haskell
implementation again, after a long stop. I’m finishing with the
implementation of everything needed by the test suite

Great news!

  • BTW, Frank,
    you did really a great job!

When the tests will be working (very soon since I just need to write
the HTML formatter for the output, now) I’ll update everything and
implement what’s still missing. So, if we set a target I’ll try to
comply with it.

So how are you actually integrating the tests? Is the "HTML formatter"
you mention specifically just for testing purposes?

I ask because Ive not yet dealt with integrating the tests in my
Python code, in part because I don’t feel I need them yet, and in part
because of the previously-mentioned fact that I’m using an internal
HTML + RDFa representation that it very different than the output in
the test suite, and so am not quite sure how to proceed. I guess I’m
thinking one way to address this is to write an “HTML-test” output
mode.

Just a question: is the “input” array in the JSON test object meant to
be a reference API, for instance with regards to name structures? The
citations object could be a reference API too, for citation prefixes,
modifiers and locators. I saw a thread above about something like
this, but I must confess that catching up with the discussions of the
last 6 month is hard… :wink:

The answer to your first question is “no, not really” but that we do
need to do something about this. I had started working on an XML
schema (which I think I committed) called csl-data.rnc whose purpose
is to be a formalization of the input expectations for CSL. Is there
interest in finishing this and including it in 1.0 final?

Bruce

FWIW. it’s here:

http://bitbucket.org/bdarcus/csl-schema/src/tip/csl-data.rnc

Part of my hesitation is I don’t want to introduce another data
format, and just intend it to be informational.

Bruce

If JSON is going to be the leading format, maybe this will be useful:
http://json-schema.org/
It probably won’t be possible to link into the rest of the CSL-schema (e.g.
to include the allowed variables and such), but that might be a relatively
small price to pay.

Rintze

FWIW. it’s here:
http://bitbucket.org/bdarcus/csl-schema/src/tip/csl-data.rnc
Part of my hesitation is I don’t want to introduce another data
format, and just intend it to be informational.

Is this intended for interchange between applications or just for
formatting data for input to a CSL processor?

Regards,
Robert.2009/12/3 Rintze Zelle <@Rintze_Zelle>:

When the tests will be working (very soon since I just need to write
the HTML formatter for the output, now) I’ll update everything and
implement what’s still missing. So, if we set a target I’ll try to
comply with it.

So how are you actually integrating the tests? Is the "HTML formatter"
you mention specifically just for testing purposes?

I ask because Ive not yet dealt with integrating the tests in my
Python code, in part because I don’t feel I need them yet, and in part
because of the previously-mentioned fact that I’m using an internal
HTML + RDFa representation that it very different than the output in
the test suite, and so am not quite sure how to proceed. I guess I’m
thinking one way to address this is to write an “HTML-test” output
mode.

Yes, the testsuite will be integrated and the HTML output will be a
very simple filter to produce the expected test result.

I think integrating the test-suite may have some benefits: a common
and standard way of testing new proposal and a way of verifying the
implementations’ compliance.

Moreover I need the tests for updating citeproc-hs, disambiguation and
collapsing particularly.

The answer to your first question is “no, not really” but that we do
need to do something about this. I had started working on an XML
schema (which I think I committed) called csl-data.rnc whose purpose
is to be a formalization of the input expectations for CSL. Is there
interest in finishing this and including it in 1.0 final?

I don’t think something like this is needed for 1.0 final and the
input expectation can be derived by the list of variables - that’s the
JSON object I expect to be the input. But when we need further details
which have consequences in terms of implementation - like with names
and dates - I think we should or could use common metadata.

Am I right when I remember some discussion about JSON/RDF (maybe that
was on the bibo ML)? Would it make any sense to reuse the
bibliographic ontology (for me that would be a good reason to write an
RDF parser for my Reference type)?

Andrea

Either the latter, or another possibility: a way to document the data
expectations. For that, we could also just use plain text in the
documentation.

Bruce

The answer to your first question is “no, not really” but that we do
need to do something about this. I had started working on an XML
schema (which I think I committed) called csl-data.rnc whose purpose
is to be a formalization of the input expectations for CSL. Is there
interest in finishing this and including it in 1.0 final?

I don’t think something like this is needed for 1.0 final and the
input expectation can be derived by the list of variables - that’s the
JSON object I expect to be the input. But when we need further details
which have consequences in terms of implementation - like with names
and dates - I think we should or could use common metadata.

Yes, this was mostly prompted by three primary issues: names, dates,
and rich text content. This is all easy to represent in XML and in
RNG.

Am I right when I remember some discussion about JSON/RDF (maybe that
was on the bibo ML)? Would it make any sense to reuse the
bibliographic ontology (for me that would be a good reason to write an
RDF parser for my Reference type)?

Yeah, discussion on BIBO takes place on the google group for that. I
do recall discussing JSON, but don’t remember the details. In this,
I’m floating the idea of some idiomatic JSON that could be easily
converted to/from BIBO RDF:

http://groups.google.com/group/bibliographic-ontology-specification-group/browse_frm/thread/317ebdd12f7aa4b1/b025bec678a4a87c?lnk=gst&q=json#b025bec678a4a87c

But it was just an idea.

Typically RDF tools have an internal model, and then they write
parsers and sterilizers for different formats (RDFXML, turtle, n3,
Trix, JSON*, etc.).

Bruce

  • Though the generic JSON they use is more verbose than JSON typically is.