Hi,
I’ve been talking to the OpenDocument people about the possibility of
including the citation style language (CSL) I designed in OpenDocument
in some form.
http://xbiblio.sourceforge.net/csl.html
One issue they raised is that it doesn’t really make use of the OD
styling infrastructure. So I’ve been experimenting a bit with what it
might mean to bring them closer in line.
Basically, it would primarily mean moving a lot of element content into
attributes. This fragment, for example, is about 75% more compact than
my current schema, and more in line with an OD approach:
<names initialize-with="." and-as=" &"/>
<months jan="Jan" feb="Feb" mar="Mar" apr="Apr" may="May" jun="Jun"
jul="Jul" aug="Aug" sep="Sep" oct="Oct" nov="Nov" dec="Dec"/>
<locator unit="page" use-when="missing-volume-issue" single="p. "
multiple="pp. "/>
<locator unit="paragraph" single="¶ " multiple="¶¶ "/>
<role term="editor" single="Ed. " multiple="Eds. "/>
<role term="translator" single="tran. " multiple="trans. "/>
<genre term="dissertation" value="PhD Dissertation"/>
<genre term="letter" value="letter"/>
<genre term="press release" value="press release"/>
<genre term="memo" value="memo"/>
<medium term="cdrom" value="CD-ROM"/>
OK, so it’s a lot more compact (and probably faster to process as a
result). What we give up with this approach is any possibility to add
markup to attribute content. So for example, current OOo code to
handle prefixes and suffixes for citations is handled in attributes.
Hence, they can only ever be strings effectively.
Is that a reasonable tradeoff? How much of a compromise would it be
worth it to get this into the OD file format?
And thinking about the document I posted the other day, how would
people imagine configuring the styling for the example which has:
author name
… citation 1 …
… citation 2 …
In other words, how would you see configuring a GUI such that you
indicate that a) citations should be grouped by author, and b) that the
group ought to be labeled with the author name, followed by a paragraph
break? It might have bearing on the above.
Bruce
Could you do this?
<role term="editor" single="Ed. " multiple="Eds. " font-style-
prefix=“italic” font-style=“regular” />
where font-style is the mark-up used for the editors name and font-
style-prefix (and -suffix) are used for the markup of those. That
should handle most needs, right? So the above should result in
something like:
Johan Kool Ed.
I’m by far not a XML expert, so I hope this makes sense.
Johan
Yes, it makes sense. However, the OD standard uses FO for font
styling, so that in reality you end up with something like:
<csl:role text:prefix="Ed. " fo:font-style=“italic” … />
… and I’m pretty sure FO has no such font-style-prefix attribute.
Have you seen examples where “Ed.” is italicized like that?
Bruce
I’m currently writing a paper for a journal that requires
"ed./eds." to be printed in italic.
I guess it would be too much work to support both CSL schemas, so
that others who require this feature and want to use CSL outside
of OOo can make use of it?
However, I think that having CSL included into the OpenDocument
format would be a very good thing. Best option would be to press
them to support styled prefixes and suffixes. 
Well, at least
it’s a valid feature request from a user point of view.
Regards, Matthias
Have you seen examples where “Ed.” is italicized like that?
I’m currently writing a paper for a journal that requires
“ed./eds.” to be printed in italic.
Well that settles it then; it stays as it is in that case 
I guess it would be too much work to support both CSL schemas, so
that others who require this feature and want to use CSL outside
of OOo can make use of it?
Yes, it’d be too much work. The challenge in this case is not really
the XML anyway, but the GUI to edit it.
However, I think that having CSL included into the OpenDocument
format would be a very good thing. Best option would be to press
them to support styled prefixes and suffixes. 
Well, at least
it’s a valid feature request from a user point of view.
Yes, and I think that’s what I need to make a case.
Bruce
Actually, correction here:
This example would still work in the alternate approach, as the "Ed."
content is actually handled with the role element:
<csl:role text:prefix=" " text:value=“Ed.” fo:font-style=“italic”/>
As I see it, the prefix/suffix stuff is really for punctuation.
Bruce
Do I understand it correctly that
- a prefix or suffix can not have its own markup?
- extra text such as Ed./Eds. and p./pp. can have its own markup?
If you go with the assumption that the prefix/suffix wil always use the same
markup as the data in question, e.g. (2005) will be all bold, than I think
you have a big majority of citations covered. I think that wanting the
brackets to be italic and the year to be bold are rare occasions.
Johan________________________________________________
Message sent using
Mailophalen 0.2.7.2
My second attempt to send this file seems to have failed too.
SourceForge doesn’t accept zip files. Download the file here: http://
sheba.geo.vu.nl/~jkool/filearea/GUI%20CSL.zip
Just a plain and quick mockup for a CSL GUI in IB for OS X. Clearly
not finished…
The empty lists should hold all the options, article, book-chapter,
editor, translator etc. The font style, prefix and suffix fields
should only be enabled when a token in NSTokenField is selected. The
current implementation for NSTokenField doesn’t allow this, but it’s
close enough to show my intentions. The plus button should show a
list with options to choose from. Multiple author stuff is not any
good yet. There are stil plenty alignment issues.
I hope this is any help/good. 
Johan
Johan Kool wrote:
My second attempt to send this file seems to have failed too.
SourceForge doesn’t accept zip files. Download the file here:
http://sheba.geo.vu.nl/~jkool/filearea/GUI%20CSL.zip
Just a plain and quick mockup for a CSL GUI in IB for OS X. Clearly not
finished…
Cool! Except, I can’t seem to get it to open right on my box.
While opening “GUI CSL.nib”, the following error occured:
*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of
class (NSTokenField)
A screenshot perhaps?
Bruce
Missed a crucial part on this sentence:
There are 4 windows now. The most Mac way to switch between these,
would, I think, be by using a toolbar with some nice icons. Like the
preference windows in many OS X apps.
Johan
Ah, you’ll need 10.4 for this.
Here are some screenshots:
There are 4 windows now. The most Mac way, would, I think, be by
using a toolbar with some nice icons.
Really nice Johan!
So are you planning to develop this into something, or were you just
playing with understanding how feasible it’d be?
One thing of note is how you’d handle the layout nesting. For example,
your “Author” field should be:
creator
name
role
And then there’s the container element. How easy is that nesting to handle?
Bruce
PS - Mind if I blog about this and use a screenshot or two?
Really nice Johan!
So are you planning to develop this into something, or were you
just playing with understanding how feasible it’d be?
Not sure yet what I’ll do.
One thing of note is how you’d handle the layout nesting. For
example, your “Author” field should be:
creator
name
role
Something like this?Op 4-okt-2005, om 20:00 heeft Bruce D’Arcus het volgende geschreven:
Johan Kool wrote:
One thing of note is how you’d handle the layout nesting. For
example, your “Author” field should be:
creator
name
role
Something like this?
No, because the names and role are nested. One finds a similar thing
with the origin field, in order to get (New York: ABC Books).
I hope there can not be a container within a container? I can’t imagine
any journal wanting to have such a reference in its articles!
You certainly could for books: chapter, book, series.
I ask about this because I’ve considered whether it might make sense to
reconsider this. There are definite advantages to this approach from a
processing standpoint, because it makes it easy to handle punctuation.
Going to a flat model would make some things more difficult. But it does
become more tricky from a GUI perspective to keep it nested.
Bruce
Oh, this page has a mockup I did in HTML of the nesting:
http://xbiblio.sourceforge.net/csl.html
Just not sure how easy that it to program (in JS, or Cocoa, etc.) …
Bruce
Johan Kool wrote:
One thing of note is how you’d handle the layout nesting. For
example, your “Author” field should be:
creator
name
role
Something like this?
No, because the names and role are nested. One finds a similar
thing with the origin field, in order to get (New York: ABC Books).
Then it’ll have to be a similar thing as I did with the container.
I hope there can not be a container within a container? I can’t
imagine any journal wanting to have such a reference in its articles!
You certainly could for books: chapter, book, series.
I ask about this because I’ve considered whether it might make
sense to reconsider this. There are definite advantages to this
approach from a processing standpoint, because it makes it easy to
handle punctuation. Going to a flat model would make some things
more difficult. But it does become more tricky from a GUI
perspective to keep it nested.
It ain’t pretty, but it’s possible to program something like this:Op 4-okt-2005, om 20:38 heeft Bruce D’Arcus het volgende geschreven:
Oh, this page has a mockup I did in HTML of the nesting:
http://xbiblio.sourceforge.net/csl.html
The problem with your implementation is that I can only see the names
of the deepest nested items. It’s important to show it, otherwise it
can get very confusing. I did another little mockup. Basically the
same, but more inspired by NSTokenField. It should handle nesting
quite nicely, as I made sure that Name within Creator is of the same
height. Otherwise you’ll get very odd things with big heights when
using deeply nested structures.
The arrow indicates that there are actions to be performed on the
item, such as adding other things and setting the fonts. It’s
important to have shortcuts here, as it otherwise can get a tedious
job to work it all with the mouse. The label “Creator” “Name” etc.
should reflect the font settings. The label (and any non-used area,
should be used for dragging and rearranging of the items.
The biggest drawback is that the amount of coding needed to create
such widget.
Nice!
The biggest drawback is that the amount of coding needed to create
such widget.
And is that because of the nesting, or just because it’s a
non-standard widget that’s doing a fair bit of work?
I had pinged a guy working on some magic javascript stuff, including
drag-and-dropable lists. Maybe I should see what he thinks about it
WRT to JS, as he wanted to implement the hierarchcal dynamic lists
this would need?
The problem with the flat approach is you need some funky way to then
artifically (from an XML perspective) link content. I always hated
the way Endnote handled that with it’s weird syntax.
Bruce
Nice!
The biggest drawback is that the amount of coding needed to create
such widget.
And is that because of the nesting, or just because it’s a
non-standard widget that’s doing a fair bit of work?
A quick look at the NSTokenField documentation makes me believe that
it should be possible to subclass it into something like we have in
mind. It’s not the nesting that’s the problem, it is very possible to
put a view in a view in a view. So the good news is that NSTokenField
seems to be a good starting point. Might our requirements proof to be
more than that, then it’s going to be a lot of work to implement the
whole control.
I’ll fiddle around a bit with this NSTokenField idea.
I had pinged a guy working on some magic javascript stuff, including
drag-and-dropable lists. Maybe I should see what he thinks about it
WRT to JS, as he wanted to implement the hierarchcal dynamic lists
this would need?
My JS is very limited. Not much more than copy-pasting interesting
things together. But my guess would be that creating such a control
in html and javascript (I think it should be called AJAX?) is very
well possible. He probably can do it. I should be able to do the
Cocoa one, I can’t do the JS one.
The problem with the flat approach is you need some funky way to then
artifically (from an XML perspective) link content. I always hated
the way Endnote handled that with it’s weird syntax.
Endnote gets so much love from you!!
JohanOp 4-okt-2005, om 23:08 heeft Bruce D’Arcus het volgende geschreven:
