Re: [O] Citations, continued

[Richard Lawrence]

Hi John and all,

John Kitchin <address@hidden> 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 address@hidden 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: address@hidden showed in address@hidden
> that this was possible. An alternative approach is illustrated in
> Ref. address@hidden

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

address@hidden :custom-type author-only] showed in address@hidden :custom-type 
year-only]
that this was possible. An alternative approach is illustrated in
address@hidden :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