(Bruce: sorry, reposting to include the list.) On Mon, Apr 4, 2011 at 2:27 AM, Bruce D'Arcus <[email protected]> wrote: > On Sun, Apr 3, 2011 at 12:49 PM, Frank Bennett <[email protected]> wrote: >> On Mon, Apr 4, 2011 at 1:26 AM, Bruce D'Arcus <[email protected]> wrote: >>> cc-ing xbib-dev on reply ... >>> >>> On Sun, Apr 3, 2011 at 12:08 PM, Frank Bennett <[email protected]> >>> wrote: >>>> After a discussion with Phillip Lord, I've made some changes in >>>> citeproc-js to provide access to the itemID inside the function used >>>> to generate the bibliography entry wrapper. One of the things this >>>> opens a path to is the inclusion of simple RDFa structures in HTML >>>> output as a set of hidden tags. >>> >>> So just to be clear, this is because of something about the way you've >>> designed the code that means that output tokens lose association to >>> metadata content during processing? >> >> It means that the itemID was not available for use in writing >> unescaped text content associated with an item, but that it now is. I >> don't know what that says about the design of citeproc-js. >> Implementing it required the addition of one line of code, and a small >> change to another. >> >>> >>> Effectively, then, you need to dump a separate representation of the >>> bib item. This would facilitate RDFa, but also any other format >>> really. >>> >>> But it does have the cost of requiring duplication of content. >>> >>> Do I have that all right? >> >> You would need a separate record of the content anyway, since field >> content may be littered with raw HTML tags, and the names data will >> often not be complete in the rendered bibliography entries. But >> otherwise, yes. The idea would be to dump a separate representation of >> the bib item. > > But for sake of possible future implementors/contributors (e.g. for > the record), one could do an object representation of the output, such > that this would be easy to do. E.g. an intermediate representation > that combines metadata and processed output strings: > > {"variable":"issued", "value":"Apr 2, 2011", "content":"2011-04-02", > "font-weight":"bold"}
Yes, that's what is needed. citeproc-js produces an object representation of the output already, all that's needed is to add a pointer to the input item and variable name when casting output, so that it can be picked up when the object is flattened. > > You then have an output routine that could write that to HTML like: > > <span > property="dc:issued" > content="2011-04-02" <!-- this holds raw value --> > style="font-weight:bold;">Apr 2, 2011</span> <!-- rendered value --> > > It's just that citeproc-js didn't take that approach, and so it's hard > to bolt on after the fact. > > Right? It's not that hard to do, really -- making the itemID available to bib items only took two lines of code. Providing access to individual variables will take a little more work, because not all variables in CSL have item content. But compared to the difficulties of getting the rendered output right, it's not a huge task. > > Not a critique; I just want people to recognize other possible approaches. > > > Bruce > I think it's more a matter of clean coding style than anything fundamental about the design. The code of citeproc-js is a little woolly in places, partly because I didn't know Javascript all that well when I started writing, and partly because the project chased emerging requirements in CSL 1.0 while it was being written. The one thing I don't like about the code is my extensive reliance on "state.tmp" values, which are in effect global variables limited in scope to the processor. With a proper inheritance mechanism, many of these could go away, and that would make the program more readable. Frank ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
