Is it really useful to have the info-classes values (“author-date” |
“numeric” | “label” | “note” | “in-text”) for the term attribute of
cs:category (style metadata)? CSL doesn’t really support generation of
labels, and the note/in-text values are redundant as they are already set in
the class attribute of cs:style. I can also imagine that style repositories
can categorize styles based on their output (e.g., styles that generate
in-text citations without alphabetic characters can be classed as numeric
styles).
The underlying question is whether it makes sense to scrap info-classes
entirely.
Rintze
Is it really useful to have the info-classes values (“author-date” |
“numeric” | “label” | “note” | “in-text”) for the term attribute of
cs:category (style metadata)? CSL doesn’t really support generation of
labels,
“label” is a synonym for “citekey”
and the note/in-text values are redundant as they are already set in
the class attribute of cs:style.
Yeah, better would be “author” and “author-date” for the in-text.
I can also imagine that style repositories
can categorize styles based on their output (e.g., styles that generate
in-text citations without alphabetic characters can be classed as numeric
styles).
The underlying question is whether it makes sense to scrap info-classes
entirely.
Well, there’s also a question I raised earlier, which is whether this
be its own element.
Bruce
Is it really useful to have the info-classes values (“author-date” |
“numeric” | “label” | “note” | “in-text”) for the term attribute of
cs:category (style metadata)? CSL doesn’t really support generation of
labels,
“label” is a synonym for “citekey”
And labels/citekeys would be supplied via the “citation-label” variable,
right?
and the note/in-text values are redundant as they are already set in
the class attribute of cs:style.
Yeah, better would be “author” and “author-date” for the in-text.
Can’t we just drop the “in-text”? How many styles do you know that only use
the author for the in-text citation?
I can also imagine that style repositories
can categorize styles based on their output (e.g., styles that generate
in-text citations without alphabetic characters can be classed as numeric
styles).
The underlying question is whether it makes sense to scrap info-classes
entirely.
Well, there’s also a question I raised earlier, which is whether this
be its own element.
Do you have a link to that discussion? (couldn’t find the thread)
Also, are there any use cases for the label and scheme attributes of
cs:category? I found this discussion:
http://74.125.77.132/search?q=cache:-IfBxrC68OQJ:plasmasturm.org/log/452/+atom+scheme+term&cd=7&hl=en&ct=clnk&client=firefox-a
and given the fact that the categories list is fixed, it doesn’t seem very
useful to me to be able to specify these other attributes.
Rintze
Is it really useful to have the info-classes values (“author-date” |
“numeric” | “label” | “note” | “in-text”) for the term attribute of
cs:category (style metadata)? CSL doesn’t really support generation of
labels,
“label” is a synonym for “citekey”
And labels/citekeys would be supplied via the “citation-label” variable,
right?
Right.
and the note/in-text values are redundant as they are already set in
the class attribute of cs:style.
Yeah, better would be “author” and “author-date” for the in-text.
Can’t we just drop the “in-text”?
Yes.
How many styles do you know that only use
the author for the in-text citation?
One really big one: MLA.
I can also imagine that style repositories
can categorize styles based on their output (e.g., styles that generate
in-text citations without alphabetic characters can be classed as
numeric
styles).
The underlying question is whether it makes sense to scrap info-classes
entirely.
Well, there’s also a question I raised earlier, which is whether this
be its own element.
Do you have a link to that discussion? (couldn’t find the thread)
No. I was just asking people to review the info section, and
suggesting that “field” and “type” or “class” could be split off from
category.
Also, are there any use cases for the label and scheme attributes of
cs:category? I found this discussion:
http://74.125.77.132/search?q=cache:-IfBxrC68OQJ:plasmasturm.org/log/452/+atom+scheme+term&cd=7&hl=en&ct=clnk&client=firefox-a
and given the fact that the categories list is fixed, it doesn’t seem very
useful to me to be able to specify these other attributes.
It’s useful to define separate controlled lists. If we don’t need
that, we don’t need this attribute.
Bruce
the category-values listed in the CSL schema, right? Which doesn’t seem
particularly useful.
Rintze
If that’s the case (and I’m not sure it is), there’s no technical
reason (w/RNG) it needs to be so. We could have a pattern that says a
category with a schema uri may have any value.
Bruce
Maybe I’m not correctly understanding line 139:
https://sourceforge.net/apps/trac/xbiblio/browser/csl/schema/trunk/csl.rnc?rev=1164#L137
It seems to me that would actually forbid extension of the terms-list,
right?
Niggle: the Atom spec uses the “scheme” attribute, not “schema”. This is
incorrect in the CSL schema annotations.
Rintze