From your e-mails I understood you wanted it to represent a number
that relates to the reference directly, such as a report or case
Do I understand it right that it can actually represent all of this,
so report or case number as well as the number in the conventional
No. Otherwise you’d end up with duplicate issue numbers; right?
To be clear, we have three kinds of numbers: document (the current
context: the reference), issue and volume. Remember, default config for
So when you use in a template, it’s basically switching
context (in XSLT terms) to the volume relation, and using its number.
Because the current context is by definition the document/reference, we
can sensibly shorten document number to just “number.”
But I don’t think we can mix what are basically incompatible models.
“Number” as used in PRISM and BibTeX is just bad design, and it means
that people have to result to hacks like articleNumber to get around
I guess edition is still another number of sorts, though of a different
Back to cs-identifier:
Besides doi, some other useful fields might be:
[… snip …]
the above from http://www.exlibrisgroup.com/sfx_openurl_syntax.htm
OK, I need a vote on what to do here, because I don’t think it’s
sensible to have 10 or 15 elements to represent this stuff. I’ve never
seen references with anything but dois in them, but I could imagine
people might want this stuff. So:
Option 1: support only the basics (doi, isbn)
Option 2: have a generic identifier element with type attributes
Option 3: support a mix of 1 and 2
This get us into large design patterns. The decision can’t be made in
total isoldation. If we go with 2, what other structures also warrant
this approach? What do not?
If you’ll remember, a bit ago I had gone with the more generic
approach, but hadn’t been that happy with it. In the end, though,
flexibility may be more important than absolute purity.
Btw, this week I’ll probably only be able to respond at irregular
times, so it may take a bit longer to reply than usual.
OK, have fun!