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
