# \[dev-biblio\] styling design question

**URL:** <https://discourse.citationstyles.org/t/dev-biblio-styling-design-question/104>\
**Category:** CSL Development\
**Created:** [October 6, 2005, 9:47am UTC](https://discourse.citationstyles.org/t/dev-biblio-styling-design-question/104 "2005-10-06T09:47:27Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [October 6, 2005, 9:47am UTC](https://discourse.citationstyles.org/t/dev-biblio-styling-design-question/104/1 "2005-10-06T09:47:27Z")

</div>

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](http://OpenOffice.org). More about those another  
> time.)

Excellent!

> 1. 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!

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