…
A related item just occurred to me, which is kind of important. The
year-suffix delimiters are numbers, and things will be much less messy
at the implementation level if they are expressed with a number
element:
Are you still advocating this?
The current schema will work, but in order to implement range joins of
the suffixes, every implementation will want to trap the
“variable-suffix” variable and recharacterize it as a number
internally. It would save a lot of confusion in the code if it were
just declared to be a number in the first place. That would also let
editors use roman numbers, or parens-enclosed arabic numerals, or
whatever as disambiguation strings, and they would all delimit and
range correctly out of the box, using standard numbers handling
machinery. A text element with a year-suffix var is bound to a single
style of presentation, which could bite down the road
(year-suffix-roman … year-suffix-roman-square-braces …).
But I don’t why this has anything in particular to do with the CSL syntax?
I personally think it’s a little awkward either way. The advantage of
the approach I took is that it required totally trivial mods to the
schema (just adding an attribute value).
Bruce
…
A related item just occurred to me, which is kind of important. The
year-suffix delimiters are numbers, and things will be much less messy
at the implementation level if they are expressed with a number
element:
Are you still advocating this?
It will work either way for the familiar a-z use case, but with a text
element, that sequencing scheme is hard-wired; you can’t easily get
roman numerals or arabic numerals. If someone came along asking for
that capability, you could cope by treating year-suffix as an
implicit number, and permitting number attributes on such variables
… but if implicit numbers behave the same whether they are rendered
through text or number, it becomes unclear what the number element is
doing there.
I don’t feel strongly about it, if it’s easier to leave it as text,
that’s fine (but secretly I might pretend that it’s a number anyway
:).
The current schema will work, but in order to implement range joins of
the suffixes, every implementation will want to trap the
“variable-suffix” variable and recharacterize it as a number
internally. It would save a lot of confusion in the code if it were
just declared to be a number in the first place. That would also let
editors use roman numbers, or parens-enclosed arabic numerals, or
whatever as disambiguation strings, and they would all delimit and
range correctly out of the box, using standard numbers handling
machinery. A text element with a year-suffix var is bound to a single
style of presentation, which could bite down the road
(year-suffix-roman … year-suffix-roman-square-braces …).
But I don’t why this has anything in particular to do with the CSL syntax?
It’s the loss of form=“roman”, mostly.
I personally think it’s a little awkward either way. The advantage of
the approach I took is that it required totally trivial mods to the
schema (just adding an attribute value).
It’s not super-difficult to recharacterize the value as a number
internally in the implementation, but it would be simpler the other
way around. More lines of code to read, more stuff to break. It’s a
judgment call, apart from the roman numerals thing.