Hi John and all, John Kitchin <jkitc...@andrew.cmu.edu> writes:
> I think the critical point is that the syntax must be user > extendable. It should be possible to add these different types, even if > most people do not use them. Otherwise, links will continue to be used > anyway. I completely agree. Some form of user extensibility is needed, not only because our existing needs are complex and diverse, but because it's hard for each of us to know how those needs will change in the future. My concern is just that we clearly distinguish the `main' or `proper' citation syntax from the user-extensible part, as I said here: >> So maybe we need some kind of inline syntax for backend-specific >> properties of citations, perhaps along the lines that Rasmus has >> suggested. I think this could be a good idea; my only concern is that >> we make a clear separation between this syntax and the main syntax for >> citations. There are two reasons for this: if we don't clearly make >> this separation, then (1) it becomes much harder to figure out and agree >> on which distinctions should be expressed in `the' citation syntax; and >> (2) there is a danger that the complexity of backend-specific properties >> will bleed over into the main citation syntax, which all backends have >> to support. To put it a different way, I think the main citation syntax should express all and only those features that are important enough that they should be supported `out of the box' -- i.e., without any user extension or customization -- for all backends. Anything else should be possible to express via whatever syntax we decide on for user extensions, but I think there should be a really clear line between the two. > I think the new citations should support an export mechanism like links > do. Each backend whould be responsible to take the information it gets, > and use it to create what it needs. Syntax like [see cite@Doe99 for > example] contains all that information, and is pretty readable. > It should be possible to define new types though. It should be > possible to define this: [citeauthor@Doe99] showed in [citeyear@Doe99] > that this was possible. An alternative approach is illustrated in > Ref. [citenum@Doe100]. Rasmus has also expressed support for something like this, and I can see that it is important for a user to be able to define types which are backend-independent (and can thus be exported differently for different backends by some user-supplied function), much like links. On the other hand, before we adopt such a facility, it's important to think about what the interface would look like. What can reasonably be expected of the user function? What information needs to be given to it? (Just the citation and its properties? a reference to the bibligraphy file? a data structure representing the referenced work?) What happens when the user doesn't define behavior for a particular backend? I don't quite like the examples you have illustrated here because they don't make the distinction I was urging above, between the `main' citation syntax and the user-extensible part. As a result it's really unclear to an author/editor, when reading the document, which backends can be expected to support which citations, and which citations can be expected to break if all you have is a default setup. (Imagine you didn't write the document or the custom citation type!) From the exporter's perspective, it's also really unclear what should happen when there's no behavior defined for, say, the "citeauthor" type for the HTML backend. If it defaults to just a "normal" citation, the output is very likely to be unreadable in the general case, but what other option is there? It's easy (and correct) to say: "These are the user's problems." But we're all users, so let's think some more about how to make things easy for ourselves. :) For these reasons, I'd prefer something like Rasmus' suggestion; maybe syntax like [@Doe99 :custom-type author-only] showed in [@Doe99 :custom-type year-only] that this was possible. An alternative approach is illustrated in [@Doe :custom-type refnum]. where, basically, ":custom-type" is a nice big flag that says: "Here be dragons: you are responsible for exporting this citation yourself." > If a multicite is something that might render as [1-3] or [1,6,9] in a > backend then yes, multicite is a necessary capability for most > scientific publications. Can you (or Tom, or someone else) make the case that it is important enough to have multicites that non-LaTeX backends should support them out of the box? (I'm not doubting it, I just don't have any idea why since I don't use them myself.) Best, Richard
