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 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
