On Wed, Feb 22, 2012 at 12:15 AM, Charles Parnot <[email protected]> wrote: > 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 > > On Feb 21, 2012, at 4:11 PM, Frank Bennett wrote: > >> On Tue, Feb 21, 2012 at 11:51 PM, Charles Parnot >> <[email protected]> wrote: >>> 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 >> >> >>> >>> >>> On Feb 21, 2012, at 3:45 PM, Dan Stillman wrote: >>> >>>> On 2/21/12 6:23 PM, Ian Mulvany wrote: >>>>> http://dx.doi.org/10.1111/j.1567-1364.2011.00787.x >>>>> " is a valid URI, >>>>> however a it seems valid DOI can be represented as >>>>> 10.1006/rwei.1999".0001 or as doi:10.1006/rwei.1999".0001 >>>>> ( >>>>> http://www.doi.org/handbook_2000/appendix_1.html#A1-C >>>>> ) and is often >>>>> represented as doi:10.1006/rwei.1999".0001 or as >>>>> doi:10.1006/rwei.1999".0001. >>>>> >>>>> It seems clear to me that all three prefixes "doi:", >>>>> >>>>> "http://dx.doi.org/"; >>>>> , and "" are going to be submitted in the wild. If >>>>> it's possible to formulate a solution that can handle all three inputs >>>>> gracefully that would be optimal. >>>>> >>>> >>>> I don't know what you're referring to in that handbook link. DOIs are just >>>> the "10." part. The "doi:" prefix and the resolver URL prefix aren't part >>>> of the DOI, and there's no reason for those to be stored in DOI fields in >>>> clients or passed around. >>>> >>>> If Frank wants to add in parsing of those things, that's up to him, but >>>> that would make about as much sense as parsing "ISBN: 123456789" or a >>>> "http://www.worldcat.org/isbn/[ISBN]"; URL. It's up to clients to pass the >>>> processor proper data. >>>> >>>> >>>>> On 21 February 2012 03:43, Rintze Zelle <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> On Mon, Feb 20, 2012 at 9:24 PM, Dan Stillman >>>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On 2/20/12 8:18 PM, Rintze Zelle wrote: >>>>>>> >>>>>>> On Mon, Feb 20, 2012 at 8:00 PM, Bruce D'Arcus >>>>>>> <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> The one that prompted this discussion is DOIs, where a link URI gets >>>>>>>> constructed out of the id, using a base URI dx.doi.org. >>>>>>>> >>>>>>> >>>>>>> Particularly for DOIs, it might be desirable to normalize the output. >>>>>>> E.g. >>>>>>> it would be nice if we could render the doi field values >>>>>>> >>>>>>> "http://dx.doi.org/10.1111/j.1567-1364.2011.00787.x"; >>>>>>> , >>>>>>> "doi:10.1111/j.1567-1364.2011.00787.x" and >>>>>>> "10.1111/j.1567-1364.2011.00787.x" all as >>>>>>> "doi:10.1111/j.1567-1364.2011.00787.x" (link title) with a href value of >>>>>>> >>>>>>> "http://dx.doi.org/10.1111/j.1567-1364.2011.00787.x"; >>>>>>> . >>>>>>> >>>>>>> In this case, we might want to make this parsing explicit in CSL. One >>>>>>> could even imagine creating a new rendering element, cs:link, for that >>>>>>> purpose. >>>>>>> >>>>>>> >>>>>>> This doesn't seem like the processor's job. All but the last one are bad >>>>>>> data. If anything, the client should normalize the values before passing >>>>>>> them through. >>>>>>> >>>>>> >>>>>> You're right. Sorry for the noise. I guess I'm just used to seeing bad >>>>>> metadata. >>>>>> >>>>>> Rintze >>>>>> >>>> ------------------------------------------------------------------------------ >>>> Keep Your Developer Skills Current with LearnDevNow! >>>> The most comprehensive online learning library for Microsoft developers >>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>> http://p.sf.net/sfu/learndevnow-d2d_______________________________________________ >>>> xbiblio-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >>> >>> -- >>> Charles Parnot >>> [email protected] >>> twitter: @cparnot >>> http://mekentosj.com >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> _______________________________________________ >>> xbiblio-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> xbiblio-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > > -- > Charles Parnot > [email protected] > twitter: @cparnot > http://mekentosj.com > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
