Here’s that earlier question, expressed in test form:
// Input book::a
{
“type”: “book”,
“author”: [
{ “name”:“Doe, John” }
],
“issued”: “2000”,
“title”: “His Anonymous Life”
}
// Test
{
“testof”: “citation”,
“csl”: “<names variable=“author”>”,
“citation”:[ {“source”:“book::a”} ],
“result”:“Doe, John”
}
Is that what should happen?
Frank
Here’s that earlier question, expressed in test form:
Thanks
// Input book::a
{
“type”: “book”,
“author”: [
{ “name”:“Doe, John” }
],
“issued”: “2000”,
“title”: “His Anonymous Life”
}
// Test
{
“testof”: “citation”,
“csl”: “<names variable="author">”,
“citation”:[ {“source”:“book::a”} ],
“result”:“Doe, John”
}
Is that what should happen?
So you’re asking about the missing cs:name child?
Answer: that style would be invalid; the cs:name child is required.
Hence, there would be no result.
Aside: rather than splitting the source data into separate files and
directories, why not just have them all in one file, and refer them by
key?
{
“book-a” : {
…
}
}
Just asking …
Bruce
Here’s that earlier question, expressed in test form:
Thanks
// Input book::a
{
“type”: “book”,
“author”: [
{ “name”:“Doe, John” }
],
“issued”: “2000”,
“title”: “His Anonymous Life”
}
// Test
{
“testof”: “citation”,
“csl”: “<names variable="author">”,
“citation”:[ {“source”:“book::a”} ],
“result”:“Doe, John”
}
Is that what should happen?
So you’re asking about the missing cs:name child?
Answer: that style would be invalid; the cs:name child is required.
Hence, there would be no result.
If articulars and suffixes are to be handled
Aside: rather than splitting the source data into separate files and
directories, why not just have them all in one file, and refer them by
key?
That probably makes sense.
Here’s the question that follows from the last:
// book::d
{
“type”: “book”,
“author”: [
{ “name”:“van Doe, Jacques” }
],
“issued”: “1645”,
“title”: “A Book of Five Rings”
}
// names::test002
{
“testof”: “citation”,
“csl”: “<names variable="author">”,
“citation”:[ {“source”:“book::d”} ],
“result”:“Jacques Doe”
}
The element for the articular is missing. Following the empty result
for the first test, should this be treated simply invalid (and
therefore returning an empty string), or valid but missing stuff (and
therefore as shown above)?
Frank
…
Here’s the question that follows from the last:
// book::d
{
“type”: “book”,
“author”: [
{ “name”:“van Doe, Jacques” }
],
“issued”: “1645”,
“title”: “A Book of Five Rings”
}
// names::test002
{
“testof”: “citation”,
“csl”: “<names variable="author">”,
“citation”:[ {“source”:“book::d”} ],
“result”:“Jacques Doe”
}
Well, I haven’t added name-part yet, but as I was thinking of it, the
result would be “Jacques van Doe.” The name-part children do not say
whether or not to print a name-part; only how to format them*.
I think this makes sense in general, but is also backward compatible.
Bruce
- which is also what I’m proposing with changes to dates.
…
Here’s the question that follows from the last:
// book::d
{
“type”: “book”,
“author”: [
{ “name”:“van Doe, Jacques” }
],
“issued”: “1645”,
“title”: “A Book of Five Rings”
}
// names::test002
{
“testof”: “citation”,
“csl”: “<names variable="author">”,
“citation”:[ {“source”:“book::d”} ],
“result”:“Jacques Doe”
}
Well, I haven’t added name-part yet, but as I was thinking of it, the
result would be “Jacques van Doe.” The name-part children do not say
whether or not to print a name-part; only how to format them*.
I think this makes sense in general, but is also backward compatible.
Okay. So a processor should require the <name … /> element to be
present, but accept <name-part … /> elements as targeted formatting
hooks (in that case the last test example would also be invalid for lack
of a element)?
(I’ll maybe tinker a little with the import machinery, to make the
CSL in the examples more human-friendly. The code should really
have the same appearance as CSL in a format file.)
Frank
…
Okay. So a processor should require the <name … /> element to be
present, but accept <name-part … /> elements as targeted formatting
hooks (in that case the last test example would also be invalid for lack
of a element)?
Correct.
(I’ll maybe tinker a little with the import machinery, to make the
CSL in the examples more human-friendly. The code should really
have the same appearance as CSL in a format file.)
This is kind of tricky, actually. if you’re going to embed CSL XML
fragments, then they should probably be proper (namespaced) XML.
Bruce
…
Okay. So a processor should require the <name … /> element to be
present, but accept <name-part … /> elements as targeted formatting
hooks (in that case the last test example would also be invalid for lack
of a element)?
Correct.
(I’ll maybe tinker a little with the import machinery, to make the
CSL in the examples more human-friendly. The code should really
have the same appearance as CSL in a format file.)
This is kind of tricky, actually. if you’re going to embed CSL XML
fragments, then they should probably be proper (namespaced) XML.
I’m not sure what would need to change to conform to that. Can
you provide a sample file?
…or:
<cs:names xmlns:cs=“http://purl.org/net/xbiblio/csl”></cs:names>
OTOH, you can take the approach that Liam took, which is just to load
full styles. See, for example:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-rb/test/test_csl.rb?view=markup
Bruce
…
Okay. So a processor should require the <name … /> element to be
present, but accept <name-part … /> elements as targeted formatting
hooks (in that case the last test example would also be invalid for lack
of a element)?
Correct.
(I’ll maybe tinker a little with the import machinery, to make the
CSL in the examples more human-friendly. The code should really
have the same appearance as CSL in a format file.)
This is kind of tricky, actually. if you’re going to embed CSL XML
fragments, then they should probably be proper (namespaced) XML.
I’m not sure what would need to change to conform to that. Can
you provide a sample file?
…or:
<cs:names xmlns:cs=“Citation Style Language - Citation Style Language”></cs:names>
Internally, this:
becomes this:
Since the namespace stuff is repetitive boilerplate (and likely to
cause extraneous problems from typos) I just kept it behind the
scenes.
OTOH, you can take the approach that Liam took, which is just to load
full styles. See, for example:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-rb/test/test_csl.rb?view=markup
Will probably use full style files when things get a little further
down the road.
…
Okay. So a processor should require the <name … /> element to be
present, but accept <name-part … /> elements as targeted formatting
hooks (in that case the last test example would also be invalid for lack
of a element)?
Correct.
Is this set doing the right thing?
// Data (book::d)
{
“type”: “book”,
“author”: [
{ “name”:“van Doe, Jacques” }
],
“issued”: “1645”,
“title”: “A Book of Five Rings”
}
// Test
{
“testof”: “citation”,
“csl”:"
",
“citation”:[ {“source”:“book::d”} ],
“result”:“Jacques van Doe”
}
Frank
Yes.
E.g. if there’s no attributes on the cs:name, print it as a display name.
Bruce