Agreed. Even though we have a custom processor that’s directly compiled with the app, it is indeed the way things are split on our end: the processor code just takes whatever data is handed to it at face value, with no extra processing. It’s up to my Papers-to-CSL translation layer to return a proper value upon request of a CSL variable.
It makes much more sense to do any parsing at the client level, since the data is also displayed to the user, and might as well be cleaned up for that purpose as well.
charles
I agree that the processor should assume clean input. The only
extension I have in mind is to (blindly) link the DOI with an anchor
in HTML output (by adding the HTML anchor tags as a wrapper, with the
stub prefix on the href of the anchor).
Frank
Ah, OK, sorry, I misunderstood as well 
It’s still unclear to me what you have in mind. Could you give an example of what the CSL would look like?
charles
Ah, OK, sorry, I misunderstood as well 
It’s still unclear to me what you have in mind. Could you give an example of what the CSL would look like?
charles
As a first step, I’m just thinking of the easy case, where a DOI or
URL is rendered in the citation output. One could just apply links
automatically by default, with a processor toggle to turn links off if
they are not desired. There wouldn’t be any impact on CSL.
I’ll be looking at HTML output first, just because I know the markup
for anchors there. Once I’ve gotten the processor to provide the
markup in HTML, it should be simple enough for someone who knows RTF
syntax to add a similar extension there.
Adding links to arbitrary portions of the output (like the title, as
Bruce suggests) would be a next step, dependent on extensions to CSL.
Frank
Frank Bennett <@Frank_Bennett> writes:
Ah, OK, sorry, I misunderstood as well It’s still unclear to me what you have in mind. Could you give an example of what the CSL would look like?
charles
As a first step, I’m just thinking of the easy case, where a DOI or
URL is rendered in the citation output. One could just apply links
automatically by default, with a processor toggle to turn links off if
they are not desired. There wouldn’t be any impact on CSL.
I’ll be looking at HTML output first, just because I know the markup
for anchors there. Once I’ve gotten the processor to provide the
markup in HTML, it should be simple enough for someone who knows RTF
syntax to add a similar extension there.
Adding links to arbitrary portions of the output (like the title, as
Bruce suggests) would be a next step, dependent on extensions to CSL.
A possible solution for the first simple step would be to inspect the
DOI variable:
Would that make sense?
A new cs:link element I believe should be the possible next step. In
this case affixes could be included in the rendered (linked) element. If
we use a link attribute for the cs:text element, affixes should instead
be excluded from the linked text, right?
Andrea
Frank Bennett <@Frank_Bennett> writes:
Ah, OK, sorry, I misunderstood as well It’s still unclear to me what you have in mind. Could you give an example of what the CSL would look like?
charles
As a first step, I’m just thinking of the easy case, where a DOI or
URL is rendered in the citation output. One could just apply links
automatically by default, with a processor toggle to turn links off if
they are not desired. There wouldn’t be any impact on CSL.
I’ll be looking at HTML output first, just because I know the markup
for anchors there. Once I’ve gotten the processor to provide the
markup in HTML, it should be simple enough for someone who knows RTF
syntax to add a similar extension there.
Adding links to arbitrary portions of the output (like the title, as
Bruce suggests) would be a next step, dependent on extensions to CSL.
A possible solution for the first simple step would be to inspect the
DOI variable:
Would that make sense?
Could we just assume that the field contains a valid DOI, since that’s
what the field is meant for? Then we could just prefix it with
http://dx.doi.org/ in the href of the anchor, and make the unprefixed
field value the content of the anchor. It will break if there is a
“doi:” or “http://dx.doi.org/” prefix written into the field, but the
breakage will encourage people to clean up their data.
Fine with me, as long as the CSL processor wrapper (e.g. Zotero and its
import/web/search translators) helps with the clean up.
RintzeOn Fri, Feb 24, 2012 at 4:18 AM, Frank Bennett <@Frank_Bennett>wrote: