This is an interesting question WRT to the spec and the test suite.
One position would be that implementations SHOULD (or even MUST)
validate styles before processing. If we said that, then there’d be no
need to test this, and the schema would be normative.
OTOH,if we don’t do that, then we do need to add a couple of cases to
the test suite. Essentially, we need to be able to say that either of
these should generate empty output (not sure how to do this in the
test suite).
… but this should correctly output the title:
<x:citation xmlns:x=“http://purl.org/net/xbiblio/csl”>
<x:layout>
<x:text variable=“title”/>
</x:layout>
</x:citation>
Bruce
If there is at least one test in the test suite that covers the issue
you’re worrying over here, you can spare the clutter in the
specification (and the abusive language as well). A footnote or
parenthetical early in the spec that contains an explanation of
namespaces and thier importance, suitable for copy-pasting, should be
sufficient to cover this.
That’s a reasonable point, but there’s one wrinkle:
The attributes in CSL are not namespaced. The elements are. Is it
misleading/confusing, then, if developers see “text” and “name”,
rather than the more correct “cs:text” and “name”?
I don’t know. I’ve never studied XML, and I’ve never claimed to
understand how namespaces work. I don’t know what the cs: prefix
signifies, and until a failing test emerges, I’ll continue to assume
that it doesn’t affect anything at the implementation level … which
adds up to the conclusion that I don’t have much useful to say, I
suppose. Maybe someone with more formal training can comment.
This is an interesting question WRT to the spec and the test suite.
One position would be that implementations SHOULD (or even MUST)
validate styles before processing. If we said that, then there’d be no
need to test this, and the schema would be normative.
OTOH,if we don’t do that, then we do need to add a couple of cases to
the test suite. Essentially, we need to be able to say that either of
these should generate empty output (not sure how to do this in the
test suite).
… but this should correctly output the title:
<x:citation xmlns:x=“Citation Style Language - Citation Style Language”>
<x:layout>
<x:text variable=“title”/>
</x:layout>
</x:citation>
Feel free to put up a test for this. To be honest, I have no idea
whether citeproc-js will play nice with it or blow up spectacularly.
If it turns out that it doesn’t work, and it’s critically important
that the processor be able to handle fragments like this, I guess I
would say three things: that I did the best I could; that it would
have been nice to have concrete tests of the case earlier in the
coding process; and that I’ll be happy to commiserate with the person
that ends up rewriting the program to conform to this requirement.
If there is at least one test in the test suite that covers the issue
you’re worrying over here, you can spare the clutter in the
specification (and the abusive language as well). A footnote or
parenthetical early in the spec that contains an explanation of
namespaces and thier importance, suitable for copy-pasting, should be
sufficient to cover this.
That’s a reasonable point, but there’s one wrinkle:
The attributes in CSL are not namespaced. The elements are. Is it
misleading/confusing, then, if developers see “text” and “name”,
rather than the more correct “cs:text” and “name”?
I don’t know. I’ve never studied XML, and I’ve never claimed to
understand how namespaces work. I don’t know what the cs: prefix
signifies, and until a failing test emerges, I’ll continue to assume
that it doesn’t affect anything at the implementation level … which
adds up to the conclusion that I don’t have much useful to say, I
suppose. Maybe someone with more formal training can comment.
This is an interesting question WRT to the spec and the test suite.
One position would be that implementations SHOULD (or even MUST)
validate styles before processing. If we said that, then there’d be no
need to test this, and the schema would be normative.
OTOH,if we don’t do that, then we do need to add a couple of cases to
the test suite. Essentially, we need to be able to say that either of
these should generate empty output (not sure how to do this in the
test suite).
… but this should correctly output the title:
<x:citation xmlns:x=“Citation Style Language - Citation Style Language”>
<x:layout>
<x:text variable=“title”/>
</x:layout>
</x:citation>
Feel free to put up a test for this. To be honest, I have no idea
whether citeproc-js will play nice with it or blow up spectacularly.
If it turns out that it doesn’t work, and it’s critically important
that the processor be able to handle fragments like this, I guess I
would say three things: that I did the best I could; that it would
have been nice to have concrete tests of the case earlier in the
coding process; and that I’ll be happy to commiserate with the person
that ends up rewriting the program to conform to this requirement.
Went the extra mile and added these tests for you to enjoy over
morning coffee. They prove that the developer has indeed apparently
“done something stupid and left out the namespaces”. All three tests
produce no output.
Good luck fixing the code, I’m clearly not qualified to do so. 
FB
I missed this earlier …
…
Went the extra mile and added these tests for you to enjoy over
morning coffee.
Thanks!
They prove that the developer has indeed apparently
“done something stupid and left out the namespaces”.
All three tests produce no output.
Good luck fixing the code, I’m clearly not qualified to do so.
To be fair, this is often a fault of the xml library. In my python
code, all xml parsing has qualified statements. See e.g.:
http://gist.github.com/138814
So the parser will always know how to handle this.
The tests shows a few common problems:
-
looking at the unqualified node name, and forgetting default
namespaces qualify their descendant nodes; so assuming “macro” ==
“{Citation Style Language - Citation Style Language}macro”.
-
hard-coding prefixes (this is a common mistake; big companies like
Apple and Yahoo make it)
I can help you fix the code if you can point out where the parsing
logic is and what I should look for. But I don’t really do much JS.
The bottom line is that xml parsing needs to include the csl
namespace.
Bruce