There is no “document” type in CSL. ?There is a “Document” item type
in the Zotero UI, but it maps to vanilla CSL “article”, (in both
Zotero 2.0 and 2.1a1).
Perhaps we should add “document”?
My (perhaps mistaken) impression was that types in CSL worked slightly
differently than other bibliographic applications. Most standard
citation styles are relatively independent of the resource type & a
well-written CSL style file reflects this. Untyped entries are kind of
implicit ‘documents’ to CSL.
Neither Zotero nor BibTeX allow untyped entries. The BibTeX ‘misc’ and
the Zotero ‘Document’ are the same beast: an explicit type to put
everything that doesn’t quite fit into any of the other defined types.
Making an explicit ‘document’ type in CSL would seem to be very odd to
me. It seems clear that it would need to posses different traits
compared to the other types used by CSL (given Bruce’s aversion to
‘misc.’), but I don’t know what those differences would be. Would “” always evaluate to ‘true’?
Can you flesh out what an explicit ‘document’ type would look like?
–Rick
There is no “document” type in CSL. ?There is a “Document” item type
in the Zotero UI, but it maps to vanilla CSL “article”, (in both
Zotero 2.0 and 2.1a1).
Perhaps we should add “document”?
My (perhaps mistaken) impression was that types in CSL worked slightly
differently than other bibliographic applications. Most standard
citation styles are relatively independent of the resource type & a
well-written CSL style file reflects this. Untyped entries are kind of
implicit ‘documents’ to CSL.
I think part of the issue here is that the logic of the type system in
CSL has evolved. For example, originally, I had this notion of
fallback types, each of which are misc. types of sorts. But that’s now
gone, because it’s not necessary with conditional support.
Neither Zotero nor BibTeX allow untyped entries. The BibTeX ‘misc’ and
the Zotero ‘Document’ are the same beast: an explicit type to put
everything that doesn’t quite fit into any of the other defined types.
Making an explicit ‘document’ type in CSL would seem to be very odd to
me. It seems clear that it would need to posses different traits
compared to the other types used by CSL (given Bruce’s aversion to
‘misc.’), but I don’t know what those differences would be. Would “” always evaluate to ‘true’?
Can you flesh out what an explicit ‘document’ type would look like?
Well, to be clear, this was just an idea I threw out. If there’s
preference to simply allowing untyped entries (e.g. if we’re talking
about json input, a record without a ‘type’ key), then that seems
reasonable to me.
Is that what you prefer?
Any other opinions? Andrea? Frank? Ron?
Bruce
The Haskell implementation of the reference record has an explicit
NoType constructor for untyped entries. This is the default in a JSON
representation of a reference - which is used if the JSON input
doesn’t have a ‘type’ key.
In other words, this is the way citeproc-hs already handles untyped
references.
Andrea
…
Well, to be clear, this was just an idea I threw out. If there’s
preference to simply allowing untyped entries (e.g. if we’re talking
about json input, a record without a ‘type’ key), then that seems
reasonable to me.
Is that what you prefer?
Any other opinions? Andrea? Frank? Ron?
So, to be concrete:
- bibtex “misc” → csl “no type”
- BIBO/Zotero “Document”–> csl [not sure]
The Haskell implementation of the reference record has an explicit
NoType constructor for untyped entries. This is the default in a JSON
representation of a reference - which is used if the JSON input
doesn’t have a ‘type’ key.
In other words, this is the way citeproc-hs already handles untyped
references.
My preference would be to require that all items submitted to the
processor have a type, and to provide an explicit document type
“false” that always tests false. That way:
(1) BibTeX “misc” and BIBO “Document” have something to map to;
(2) Consistency validation of mappings (as described in my earlier
mail) is made easy; and
(3) The behavior of the CSL code that calls this “type” is transparent.
Frank
Bruce wrote:
Well, to be clear, this was just an idea I threw out. If there’s
preference to simply allowing untyped entries (e.g. if we’re talking
about json input, a record without a ‘type’ key), then that seems
reasonable to me.
Is that what you prefer?
I don’t have a very strong preference. However, it pleases me
aesthetically to not have ‘misc’, ‘document’, ‘NoType’, or ‘false’ as
enumerated types in CSL.
The CSL vocabulary can differ a bit from citeproc implementations,
though. I think that Andrea’s description of what citeproc-hs does
“behind the scenes” is sound: assign ‘NoType’ (or type=false) explicitly
to references that lack them (I would go slightly further to use this
for any unrecognized types too).
In my perfect world:
(1) CSL vocabulary re. types would not be changed
(2) Items submitted to the CSL processor SHOULD (but not “must”) have a
valid type & “NoType” would be one such valid type.
(3) If a type is not given or an invalid type is given, the processor
MUST emit a warning but SHOULD render the data by treating the item as
“NoType”.
I haven’t written a citeproc implementation, so this shouldn’t carry
much weight. This scheme shares some of the advantages that Frank lists:
(1) BibTeX’s “misc” & BIBO/Zotero’s “Document” have explicit mapping
(already used in citeproc-hs)
(2) Mappings can be validated, but the processors can use common sense
for partial or invalid data
(3) CSL, itself, does not change
–Rick
Bruce wrote:
Well, to be clear, this was just an idea I threw out. If there’s
preference to simply allowing untyped entries (e.g. if we’re talking
about json input, a record without a ‘type’ key), then that seems
reasonable to me.
Is that what you prefer?
I don’t have a very strong preference. However, it pleases me
aesthetically to not have ‘misc’, ‘document’, ‘NoType’, or ‘false’ as
enumerated types in CSL.
The CSL vocabulary can differ a bit from citeproc implementations,
though. I think that Andrea’s description of what citeproc-hs does
“behind the scenes” is sound: assign ‘NoType’ (or type=false) explicitly
to references that lack them (I would go slightly further to use this
for any unrecognized types too).
In my perfect world:
(1) CSL vocabulary re. types would not be changed
(2) Items submitted to the CSL processor SHOULD (but not “must”) have a
valid type & “NoType” would be one such valid type.
(3) If a type is not given or an invalid type is given, the processor
MUST emit a warning but SHOULD render the data by treating the item as
“NoType”.
I haven’t written a citeproc implementation, so this shouldn’t carry
much weight. This scheme shares some of the advantages that Frank lists:
(1) BibTeX’s “misc” & BIBO/Zotero’s “Document” have explicit mapping
(already used in citeproc-hs)
(2) Mappings can be validated, but the processors can use common sense
for partial or invalid data
(3) CSL, itself, does not change
I’d be pretty happy in Rick’s perfect world. If I understand correctly:
(a) the implication of (3) is that “NoType” is NOT valid as a type=
attribute, on cs:if and cs:else-if nodes; and
(b) “NoType” IS allowed as a valid “type” value for input validation
purposes (for integration testing et cetera).
I withdraw the “type ‘false’ that tests false” suggestion. Silly idea.
Frank