Hi Peter,
(I’m new here. I work for the University of Southern Queenland on an
Australian government funded project to do with repositories, and on
an open source content management system for courseware, which is
tightly integrated with OpenOffice.org. More about those another
time.)
Excellent!
- Will there be conditional logic required? Eg if element a exists
then output b,c else output d. This sort of thing makes a CSL GUI very
hard to design.
There is some conditional logic there already, but it’s pretty simple.
For example:
<creator alternate-sortkey="container-title">
<names/>
</creator>
And a similar approach works for handling stuff like substituting
“Anonymous” instead.
Likewise, I do some tricks to enable something similar when I have
something like this:
<creator>
<names/>
<role>
<prefix> (</prefix>
<suffix>).</suffix>
</role>
<suffix/>
</creator>
… and then elsewhere do:
<role term="translator">
<renderas>
<single>tran.</single>
<multiple>trans.</multiple>
</renderas>
</role>
That means:
if creator.role = translator then
if single print tran.
else print trans.
That goes a long way and is easy to do in a GUI, and I don’t favor
going much further.
(Do we really need a GUI? for citiation and
bibliography formats most users will be consumers of preset formats,
not creators.)
This is indeed a question. What I think would be the ideal circumstance
is to have an online repository of CSL files where a user could
download (either via browser or web service) the styles they needed.
Those styles would ideally be provided by the institutions that specify
them.
However, as that’s unlikely in all cases, nicer still would be if that
repository also had a nice – AJAXified – CSL creation and editing
GUI. For the most part, users would be creating new styles by
trivially modifying existing ones. I don’t pretend that’s easy, but I
have designed CSL with that in mind.
It’s worth noting the Endnote style repository has over a 1000 of them!
- What are the chances of getting it into OpenDocument in a political
sense? I have no idea about what would be involved but I can imagine
it could be hard work, and difficult to get heard.
We have a pre-existing relationship with them (I wrote a
citation-coding proposal with one of their engineers awhile back, and
they accepted it), so it’s not hard from the standpoint of being heard.
They respect my expertise here.
The problem is more to fit it within their charter and design goals. I
don’t think Michael Brauer (the TC chair) would object to my quoting
him here:On Oct 6, 2005, at 2:38 AM, pt wrote:
========
The situation here is similar as for the bibliographic data schema. The
OpenDocument TC may include CSL into OpenDocument, but it is in my
opinion not covered by the TC’s charter to standardize CSL itself.
However, other file format of cause could reuse OpenDocument’s citation
style, and applications may support OpenDocument’s citation style
without supporting OpenDocument itself.
I’m open for a discussion to include CSL into OpenDocument, but the
concerns that I have with the current CSL schema is that it defines its
own formatting properties but does not reuse OpenDocument’s. This in my
opinion would break OpenDocument’s paradigm to have one schema for one
concept.
So as you can see, there are some challenges here, but it’s a
possibility they’re willing to consider. My questions about refactoring
CSL a bit were with this in mind. They already have bib style config in
the file format; it’s just really limited.
This is only an idea, but both of these considerations made me think
of leveraging XSLT. If there is a need for conditional elements, then
we could use XSLT’s xsl:if and xsl:choose, rather than inventing new
machinery - ie add if and choose to CSL and be guaranteed of easy
implementation using XSLT.
You can think of CSL as a dedicated templating and parameter-setting
language. I have had people tell me it’s a bad idea to try to create
this language-independent style, and that I should have just used a
full language like XSLT.
But I really don’t like this idea, as to me language-independence is
really important here. I really want to see citeproc-py or citeproc-pl,
and to see people implement it for use with LaTeX or RTF. I think it’s
a mistake to do the lower-level approach (as in BibTeX, or some of the
Perl-based approaches; indeed I just talked to a guy who wrote one of
the latter, and was actually looking for something like CSL to replace
his Perl-based styling code).
There’s also the issue that this stuff is hard to do in XSLT 1.0 in
particular (though if you guys want to try and prove me wrong that’d be
great!) …
And it also occurred to me that maybe it would be possible to ship
XSLT with an OD document. So instead of including a CSL spec, one
could ship an XSLT derived from a CSL spec that would operate on the
content. So OOo would not have to know about CSL, just have a
mechanism for running an XSLT stylesheet across the content of a
document to produce a new version.
True. But have you seen my stylesheets? They’re written in XSLT 2.0,
which beyond offering a lot more power over a 1.0-compliant equivalent,
also allows me to make them likely much shorter. So that embedded XSLT
file would be really large. Even if we could rely on 2.0, they’d still
be much larger than a CSL file. If I had to guess, I’d say we’re
talking an order of magnitude difference.
It may be possible to strip a lot of that code out if your dealing with
a static XSLT, but I still think it’d be large. Also, it would only
work on applications that support that processing model. The nice
thing about OD is that whatever we get in their becomes bigger than OOo
even.
Bruce