But is it necessary to do this with markup, and reasonable to expect
users to create that?
Bruce
…
- It missed out another use case, for the “v.” in case names, for
which both capitalization and decorations should be suppressed.I have adjusted the parser code to use …
and … instead, for the two cases
respectively.I’m not following the “decoration” use case here. In the csl-data
schema, I just have a single “protect” class, which corresponds to
BibTeX’s use of brackets. Why is that not enough?There are two use cases. For concrete-ish examples …
If the following is produced using text-case=“sentence”, the proper
name needs to be escaped for text mangling, but not for decorations:Metaphorical subtext in Bullshot Crummond …
My current markup in the data for this title would be:
Metaphorical Subtext in Bullshot Crummond
If the following is produced in any style, the “v.” needs to be
escaped for decorations. Currently I also escape it for text
mangling:Lessard v. Schmidt …
My current markup in the data for this title would be:
Lessard v. Schmidt
BibTeX cannot handle the second use case, but it doesn’t need to
because it is never used to process legal citations (or if it is,
users excuse the fact that it does not print them correctly).But is it necessary to do this with markup, and reasonable to expect
users to create that?
I’m assuming a user interface. But if there is another, simpler way
forward, that would be great. (At the moment, most of us seem to be
doing all of this stuff by hand in the word processor.)
Well, beyond “v.”, what are the use cases?
Bruce
I’m assuming a user interface. But if there is another, simpler way
forward, that would be great. (At the moment, most of us seem to be
doing all of this stuff by hand in the word processor.)Well, beyond “v.”, what are the use cases?
There are also judgements with names like In re Smith. Among
adversarial case names, there might be jurisdictions or reporters that
use a separator other than “v.”. In the former case, splitting the
field into two parts would raise processor-level validation issues
(what happens if only the field for the right side has data, etc.),
and in the latter we’d run into trouble trying to parse the “v.” out
of the raw string. Putting a “print me as I stand” wrapper around the
v. seems the simplest solution.
In operation, the wrapper tags can be applied by a translator/scraper
when the data is harvested, and if there are exceptional cases they
can be patched up with an editor. If there is a more elegant
approach, I haven’t been able to think of it.