Speaking of annotated bibliographies, typical antiquarian book catalogs are
just bibliographies with extensive annotation (and sometimes photos). I
wonder if CSL could handle them.
Here are a few examples:
http://www.royoung.com/Winter_2006.pdf
http://www.maggs.com/pdfcatalogues/1364.pdf.
http://www.auew74.dsl.pipex.com/PDF/Cat775WinterMisc.pdf
John
Not fully. We don’t have variables for some of the stuff they care
about (price, for example).
Bruce
We don’t have variables for some of the stuff they care about (price, for
example).
How would/should things work if I want a new field such as this? If as a
user of a CSL-based bib tool or as a developer of styles, I see that I need
a variable that’s not in the schema, what should I do?
It looks from the one style I’ve been studying (apa.csl) that if I were to
simply use variable=“price” in my csl and my data source had such a field,
that the formatter would do the right thing, even though “price” is not in
the list of variables defined in the schema.
In my sketch for a VB-based formatter inside Word 2007, I was going to have
it work that way.
John
John P. McCaskey wrote:
We don’t have variables for some of the stuff they care about (price, for
example).How would/should things work if I want a new field such as this? If as a
user of a CSL-based bib tool or as a developer of styles, I see that I need
a variable that’s not in the schema, what should I do?It looks from the one style I’ve been studying (apa.csl) that if I were to
simply use variable=“price” in my csl and my data source had such a field,
that the formatter would do the right thing, even though “price” is not in
the list of variables defined in the schema.
I really think we all need to talk about some ground rules for exactly this.
My argument is that if a file does not validate against the CSL schema,
it is not a CSL style. And I think implementors should be checking
validity if possible (maybe we need a simple little web service for this?).
I also think CSL styles need to be publicly accessible from at least the
link URI in the their metadata.
I think when we come to doing the actual spec, we need to agree on some
sort of conformance language then.
Now, WRT to your question on extra fields and such, a style using such a
variable would be invalid against the default schema. There are thus two
options:
create a custom extension schema in which you override the extension
patterns with your own.
post a note here asking for inclusion in the schema proper
We probably ought to favor adding variables if in doubt.
OTOH, I’m a little leary about opening up the scope too much.
Bruce
We don’t have variables for some of the stuff they care about (price, for
example).How would/should things work if I want a new field such as this? If as a
user of a CSL-based bib tool or as a developer of styles, I see that I need
a variable that’s not in the schema, what should I do?It looks from the one style I’ve been studying (apa.csl) that if I were to
simply use variable=“price” in my csl and my data source had such a field,
that the formatter would do the right thing, even though “price” is not in
the list of variables defined in the schema.I really think we all need to talk about some ground rules for exactly this.
My argument is that if a file does not validate against the CSL schema,
it is not a CSL style. And I think implementors should be checking
validity if possible (maybe we need a simple little web service for this?).I also think CSL styles need to be publicly accessible from at least the
link URI in the their metadata.I think when we come to doing the actual spec, we need to agree on some
sort of conformance language then.Now, WRT to your question on extra fields and such, a style using such a
variable would be invalid against the default schema. There are thus two
options:
create a custom extension schema in which you override the extension
patterns with your own.post a note here asking for inclusion in the schema proper
We probably ought to favor adding variables if in doubt.
OTOH, I’m a little leary about opening up the scope too much.
Bruce
There are certainly many cases where a user or user community will legitimately want fields that won’t make it into the schema, and even more that wouldn’t make it into the schema quickly enough to meet the user needs. I can think non-stop of cases of each.
How about this:
There are three items whose compliance is at issue, the schema, the style, and the citation processor (formatter).
Schema: It will evolve with user input, but at any point in time, there should be and will be an official schema. Any deviations are non-compliant. Any deviants are not CSL schemas.
Styles: For a style to be a CSL style, it must validate against the official schema.
Citation processor: To be a CSL citation processor, it must be able to process styles compliant with the then official schema. It may, at its maker’s option offer the ability to process variables beyond those in the official schema. Preferably, the processor would have a STRICT flag that when set would force the processor to reject any style that does not validate. But without this flag set, a processor would process undefined variables as expected.
To add a user-defined field, a user could add the field to the source database and modify the style file. That file would now not be compliant but if he is using a processor that handles such extensions, the user could get his job done.
If a whole community of users wanted to allow styles that use a variable important to that community (Vatican, Scandinavians, Quebecois, military researchers, etc., etc.), but the CSL committee has not or has not yet blessed its use, that community could introduce a new schema. It would not be CSL compliant but would allow the community to enforce standards. If that community were using formatters that handle additional variables, the community would benefit greatly from tracking the official CSL schema, tracking CSL styles, and using CSL-based processors. The community would also benefit from adopting an architecture that lets it enforce standards instead of relying on each user to make the correct modifications locally.
It all comes down to the formatter. If a formatter handles variables outside the schema, then something like the above will happen. Makers of formatters will have a great incentive to offer such a feature, even if also offering a STRICT mode.
John