Questions, Comments, and Reminders

I need to repeat publisher to do:

So what if we had this as a default?

E.g. allow the delimiter attribute on publisher?

I guess that doesn’t help for the case where you include the date, but
maybe there’s a similarly simple way to address that?

This also explains why I prefer simple top-level fields. Once you
remove , is there any reason to have </

and not just ?

One problem is that there may be other kinds of relevant “place”
variables? For example, the place of a conference, or a hearing.

Either we’ll be making authors use
everywhere (or define a macro to handle
this in nearly every document), or we’ll need to make
actually do something. In my view, the latter is much more intuitive
than the former.

OK, let’s look at the chicago-a style. We have stuff like:

            <issue prefix=", ">
              <label form="short" text-transform="lowercase" 

suffix=". "/>

There’s no way around needing to define the label and its location
relative to the number. Is there really a completely clean, simple, way
to do this?

Right now, we could define this in the defaults:

            <locator prefix=", ">
              <label form="short" text-transform="lowercase" 

suffix=". "/>

I guess what you’re saying is that is only so helpful and that you
might also want to globally define other macros apart from the generic?

Bruce

Remember, this is a generic model with basically some syntactical
sugar. The relation attribute is necessary to avoid a really long list
of elements like:

<originalTranslatedCollectionTitle/>

… and so forth.

The “container” and “collection” things are basically standard
bibliographic levels, supported in a lot of models. So a collection
title includes series titles, but also archival collection titles, and
so forth.

Important to, BTW, to wrap your head around the importance of the three
default templates (article, book, chapter).

Bruce

  1. Reminder: should in some way be able to display “and
    others”.

OK, this should be taken care of, as well as Simon’s request to allow
more top-level fields.

  1. Reminder: we should add the following form values to :
    form=“verb-short” and form=“verb-long”. This will display “ed. by” and
    “edited by” respectively.

This raises and issue: the current schema and localization files are
not in sync.

I think I fixed all that (there was a lot). Let me know how it goes.

Bruce

I need to repeat publisher to do:

So what if we had this as a default?

E.g. allow the delimiter attribute on publisher?

I guess that doesn’t help for the case where you include the date, but
maybe there’s a similarly simple way to address that?

How, then, do we handle what we could currently model as:

... ... ...

Or, with top-level fields:

(This issue doesn’t exactly necessitate top-level fields, since we
could also make the conditional more complex and deal with it that
way, but top-level fields provide the most compact syntax. If we do
add macros, we should make sure to offer an macro attribute on .)

This also explains why I prefer simple top-level fields. Once you
remove , is there any reason to have </

and not just ?

One problem is that there may be other kinds of relevant “place”
variables? For example, the place of a conference, or a hearing.

We could put an attribute on to accommodate these, or else
use . As far as I can tell, CSL doesn’t yet support
these at all.

OK, let’s look at the chicago-a style. We have stuff like:

            <issue prefix=", ">
              <label form="short" text-transform="lowercase"

suffix=". "/>

There’s no way around needing to define the label and its location
relative to the number. Is there really a completely clean, simple,
way
to do this?

Well, as long as you know it’s , you can use .

Right now, we could define this in the defaults:

            <locator prefix=", ">
              <label form="short" text-transform="lowercase"

suffix=". "/>

…which brings up a very important issue. What do we do with the
element in , which just represents a generic
locator? I’m not quite sure what to do in this case, but I would
suggest either keeping the current syntax, or using:

Finally, looking over the CSL schema, I realize that there are cases
where my styles won’t validate because you’re very restrictive about
what you let in the /style/citation/layout/item element. Why is this?
There isn’t any reason fields in the element need to be
treated differently from fields in the element. It
makes the language much less flexible without making it any easier to
code a parser.

I’d be happy to provide an updated schema that implements everything
that I’ve mentioned here, and to provide an example of a style using
the modified schema. If we agree that the approach is successful, I
can write a tool to convert existing styles to the new format.

Simon

What’s wrong with:

Simon

Finally, looking over the CSL schema, I realize that there are cases
where my styles won’t validate because you’re very restrictive about
what you let in the /style/citation/layout/item element. Why is this?
There isn’t any reason fields in the element need to be
treated differently from fields in the element. It
makes the language much less flexible without making it any easier to
code a parser.

But the idea is that it is easier for a human author. Remember, in
essence, the class attribute (“author-date” and so forth) is there as a
hint to a validator, and related real-time validating editors. You can
always use the generic class and remove the restrictions.

E.g. lack of flexibility is a feature!

That said, clearly if there are places where I am too restrictive
(maybe not including more recent structures), that ought to be loosened
up.

I’d be happy to provide an updated schema that implements everything
that I’ve mentioned here, and to provide an example of a style using
the modified schema. If we agree that the approach is successful, I
can write a tool to convert existing styles to the new format.

OK, give it a shot.

Bruce

User has to duplicate the two fields everywhere they want a title.

Bruce

While under the current approach, this might be unsatisfactory, with
a macro, it doesn’t take any more tags than having a
element, and is perhaps slightly simpler to figure out.

Simon

Forgot to send this the other day …

One problem is that there may be other kinds of relevant “place”
variables? For example, the place of a conference, or a hearing.

We could put an attribute on to accommodate these, or else
use .

See below …

As far as I can tell, CSL doesn’t yet support
these at all.

That’s probably true: but that’s an oversight that does not change the
point that we need to solve this in a general way.

It’s a bad idea IMHO to treat publisher and place as ambiguous flat
fields in ways that are inconsistent with other structures (notably
contributor).

A publisher is an organization responsible for distributing some
citable thing. It has a name, and it has an address (place).

So a relation attribute might be reasonable, but I’m not clear why
“publisher” is a problem now. Alternately, I wonder whether we can
think of some better top-level “macro.”

Bruce

Simon,On Mar 25, 2007, at 11:20 PM, Simon Kornblith wrote:

I’d be happy to provide an updated schema that implements everything
that I’ve mentioned here, and to provide an example of a style using
the modified schema. If we agree that the approach is successful, I
can write a tool to convert existing styles to the new format.

Can I get you to comment on if/when/how you intend to proceed with
this? Obviously the sooner we can happily call CSL 1.0, the better …

Bruce