Here is a testing sample for minimal name expansion. Passes in
citeproc-js, to my own amazement.
Data:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-js/branches/fbennett/std/items/ambigs-4.txt?revision=831&view=markup
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-js/branches/fbennett/std/items/ambigs-5.txt?revision=831&view=markup
Frank
I tried them, and tried to break citeproc-js: it seems like you are
doing a great job.
I’m going to implement your test suite for -hs too. Just one question:
what kind of output do you expect when it comes to formatting? I saw a
few HTML tags…
Andrea
I’d also like to raise another issue I’ve raised before: namespaces. A
correct XML parser will not understand the CSL fragments in the tests
as valid. E.g.,using Python lxml library (which is an etree-compatible
API on top of libxml), an expression like
csl.find(’/style/info/title’) will return nothing. Where a library
does return something, that’s effectively bug (if a convenient one).
So shouldn’t the test fragments be properly namespaced?
Bruce
Here is a testing sample for minimal name expansion. Passes in
citeproc-js, to my own amazement.I tried them, and tried to break citeproc-js: it seems like you are
doing a great job.I’m going to implement your test suite for -hs too. Just one question:
what kind of output do you expect when it comes to formatting? I saw a
few HTML tags…I’d also like to raise another issue I’ve raised before: namespaces. A
correct XML parser will not understand the CSL fragments in the tests
as valid. E.g.,using Python lxml library (which is an etree-compatible
API on top of libxml), an expression like
csl.find(‘/style/info/title’) will return nothing. Where a library
does return something, that’s effectively bug (if a convenient one).So shouldn’t the test fragments be properly namespaced?
They are wrapped in style and citation elements before rendering, so a
namespaced object does reach the processor. Would it be enough to
document that?
Now that you mention it, though, there does need to be a change to the
file syntax. Instead of “csl”, it should be “locale”, “macro”,
“citation” and “bibliography”. That would also help make it clear
that there’s a template behind the fragments. Or we could just
include the whole object in the test. Which is preferable? I’m easy,
I’ll just wait for guidance before refactoring the files.
Frank
…
So shouldn’t the test fragments be properly namespaced?
They are wrapped in style and citation elements before rendering, so a
namespaced object does reach the processor. Would it be enough to
document that?Now that you mention it, though, there does need to be a change to the
file syntax. Instead of “csl”, it should be “locale”, “macro”,
“citation” and “bibliography”. That would also help make it clear
that there’s a template behind the fragments. Or we could just
include the whole object in the test. Which is preferable? I’m easy,
I’ll just wait for guidance before refactoring the files.
What do mean by the “template behind the fragments” and the “wrapped
… before rendering” comments? That you literally do that as part of
the fixture construction?
Also, by “whole object” are you referring to the complete CSL file?
Bruce
…
So shouldn’t the test fragments be properly namespaced?
They are wrapped in style and citation elements before rendering, so a
namespaced object does reach the processor. Would it be enough to
document that?Now that you mention it, though, there does need to be a change to the
file syntax. Instead of “csl”, it should be “locale”, “macro”,
“citation” and “bibliography”. That would also help make it clear
that there’s a template behind the fragments. Or we could just
include the whole object in the test. Which is preferable? I’m easy,
I’ll just wait for guidance before refactoring the files.What do mean by the “template behind the fragments” and the “wrapped
… before rendering” comments? That you literally do that as part of
the fixture construction?
Yes, at the moment there is a template that works something like this:
%%CSL%%But I think you’re right, the test should provide the full namespaced
CSL object, for clarity. It saved some typing to use a template, but
it’s not transparent enough and requires too much pre-processing for
standard tests. Shall I refactor things? It’s easy to do.
Also, by “whole object” are you referring to the complete CSL file?
Yes.
…
But I think you’re right, the test should provide the full namespaced
CSL object, for clarity. It saved some typing to use a template, but
it’s not transparent enough and requires too much pre-processing for
standard tests. Shall I refactor things? It’s easy to do.
Yes, please do. As you say, it’s more transparent.
Bruce
…
But I think you’re right, the test should provide the full namespaced
CSL object, for clarity. It saved some typing to use a template, but
it’s not transparent enough and requires too much pre-processing for
standard tests. Shall I refactor things? It’s easy to do.Yes, please do. As you say, it’s more transparent.
Done.
Now that CSL 0.8 has been tagged, I have a question related to namespaces.
Are there any backward incompatible changes planned for CSL 1.0? If so, is
it correct to keep the namespace in all styles pointing to “
http://purl.org/net/xbiblio/csl”? Shouldn’t styles in that case name the
CSL-version for which they are validated (e.g. all the current styles in the
Zotero Style Repository could point to CSL 0.8)?
Rintze
Now that CSL 0.8 has been tagged, I have a question related to namespaces.
Are there any backward incompatible changes planned for CSL 1.0?
Probably some minor ones.
If so, is it correct to keep the namespace in all styles pointing to
“Citation Style Language - Citation Style Language”? Shouldn’t styles in that case name the
CSL-version for which they are validated (e.g. all the current styles in the
Zotero Style Repository could point to CSL 0.8)?
I think it depends. The problem with using namespaces to version is
that you then require code be updated across the board to handle those
different namespaces. From an XML perspective, they are effectively
different schemas.
There’s two other approaches to versioning:
the “don’t worry about it approach”; only works in this case if ALL
implementations agree to it and figure out how to handle upgrading
add something like a schema version attribute to the root, so that
a tool knows which schema version to use for validation, and then for
parsing
I guess my vote would be to try to see if we can take the #1 approach
to get us to 1.0, and then use #2 beyond that (hoping we don’t have to
introduce any significant changes later).
But we should add this to the list of issues to resolve.
One of the Mendeley devs joined this list, BTW, but he’s busy
squashing bugs for a new release. We need their input on this, suffice
to say.
Bruce2009/3/31 Rintze Zelle <@Rintze_Zelle>: