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… 
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.