low-level vs. high-level style config

Just to illustrate my earlier point on the new CSL editor being quite
low-level, my point is that the following is another way to represent
a (very minimal) style …

{
“macros”: {
“author-editor”: “http://zotero.org/apa#author-editor”,
“date”: “http://zotero.org/apa#year”,
“title”: “http://zotero.org/apa#title
},
“citation”: {
“options”: {
“et-al-min”: “3”,
“et-al-use-first”: “3”
},
“layout”: [
{
“macro”: “author-editor”,
“suffix”: " "
},
{
“macro”: “date”,
“prefix”: “(”,
“suffix”: “)”
},
{
“macro”: “title”,
“prefix”: " "
}
]
}
}

So the focus is on macros, and on macro reuse. Any type-specific
formatting details get configured in the macros.

As I noted, though, they’re not necessarily mutually exclusive
approach. I just think this approach is much easier as the basis of a
wizard-like interface for the vast majority of cases, given that the
(Zotero) community has already done most of the work by defining
reusable macros.

Bruce

Just to illustrate my earlier point on the new CSL editor being quite
low-level, my point is that the following is another way to represent
a (very minimal) style …

{
“macros”: {
“author-editor”: “Zotero | People > apa”,
“date”: “Zotero | People > apa”,
“title”: “Zotero | People > apa
},
“citation”: {
“options”: {
“et-al-min”: “3”,
“et-al-use-first”: “3”
},
“layout”: [
{
“macro”: “author-editor”,
“suffix”: " "
},
{
“macro”: “date”,
“prefix”: “(”,
“suffix”: “)”
},
{
“macro”: “title”,
“prefix”: " "
}
]
}
}

So the focus is on macros, and on macro reuse. Any type-specific
formatting details get configured in the macros.

This is interesting. Should CSL processors themselves be capable of
macro overloading? I can see how it would open the path toward a
repository of well-defined macros that are independent of a particular
style, which would be good all around.

It shouldn’t be hard to implement. The only problem for citeproc-js
is that our JS interpreters that can be run from command-line
(spidermonkey and rhino) have crippled i/o and wouldn’t be able to
test URL-based fetches directly. But that can be sorted out on
deployment.

Anyway, if this fits your line of thinking about style development and
maintenance, I’d be glad to take a closer look at the problem.

Frank

Just to illustrate my earlier point on the new CSL editor being quite
low-level, my point is that the following is another way to represent
a (very minimal) style …

{
“macros”: {
“author-editor”: “Zotero | People > apa”,
“date”: “Zotero | People > apa”,
“title”: “Zotero | People > apa
},
“citation”: {
“options”: {
“et-al-min”: “3”,
“et-al-use-first”: “3”
},
“layout”: [
{
“macro”: “author-editor”,
“suffix”: " "
},
{
“macro”: “date”,
“prefix”: “(”,
“suffix”: “)”
},
{
“macro”: “title”,
“prefix”: " "
}
]
}
}

So the focus is on macros, and on macro reuse. Any type-specific
formatting details get configured in the macros.

This is interesting. Should CSL processors themselves be capable of
macro overloading?

Not necessarily. I’m imagining here a little script that assembles the
CSL. Take all the dependent styles in the Zotero repo, normalize the
macro names, and it’s then easy to extract them. This is the idea
behind the CSLGallery web app in the svn.

I can see how it would open the path toward a
repository of well-defined macros that are independent of a particular
style, which would be good all around.

Right.

It shouldn’t be hard to implement. The only problem for citeproc-js
is that our JS interpreters that can be run from command-line
(spidermonkey and rhino) have crippled i/o and wouldn’t be able to
test URL-based fetches directly. But that can be sorted out on
deployment.

Anyway, if this fits your line of thinking about style development and
maintenance, I’d be glad to take a closer look at the problem.
Frank

I don’t think you need to worry about this in citeproc-js per se.

Bruce

Just to illustrate my earlier point on the new CSL editor being quite
low-level, my point is that the following is another way to represent
a (very minimal) style …

{
“macros”: {
“author-editor”: “Zotero | People > apa”,
“date”: “Zotero | People > apa”,
“title”: “Zotero | People > apa
},
“citation”: {
“options”: {
“et-al-min”: “3”,
“et-al-use-first”: “3”
},
“layout”: [
{
“macro”: “author-editor”,
“suffix”: " "
},
{
“macro”: “date”,
“prefix”: “(”,
“suffix”: “)”
},
{
“macro”: “title”,
“prefix”: " "
}
]
}
}

So the focus is on macros, and on macro reuse. Any type-specific
formatting details get configured in the macros.

This is interesting. Should CSL processors themselves be capable of
macro overloading?

Not necessarily. I’m imagining here a little script that assembles the
CSL. Take all the dependent styles in the Zotero repo, normalize the
macro names, and it’s then easy to extract them. This is the idea
behind the CSLGallery web app in the svn.

I can see how it would open the path toward a
repository of well-defined macros that are independent of a particular
style, which would be good all around.

Right.

It shouldn’t be hard to implement. The only problem for citeproc-js
is that our JS interpreters that can be run from command-line
(spidermonkey and rhino) have crippled i/o and wouldn’t be able to
test URL-based fetches directly. But that can be sorted out on
deployment.

Anyway, if this fits your line of thinking about style development and
maintenance, I’d be glad to take a closer look at the problem.
Frank

I don’t think you need to worry about this in citeproc-js per se.

(whew!)

I updated the earlier MakeCSL mockup to illustrate visually what I mean:

http://www.users.muohio.edu/darcusb/citations/MakeCSL/

The details are mostly missing, and described in place-holder text (in
brackets), but there should be enough to communicate the idea. If you
click, for example, on the “bibliography” tab, and then the “display
order” you should get a list, which you can drag-and-drop reorder.

With more time, and more skill, there’s still a lot that could be
built on top of this. For example, it’s easy enough with JQuery to
have a separate list of possible macros, which can then be dropped
onto the sortable “order” list. I’d also expect to embed the prefix
and suffix forms in the list items.

Bruce