Inheritance and classes

CSL Development
1

Currently, the CSL schema defines inheritance as follows:

Base fields, many of which are compound. The override logic is that

if there is a child of a field other than cs:substitute, then the

default template is overridden. Otherwise, fields inherit from their

default definitions.

This means that if a default template specifies child elements, and a field
specifies only a element, the default template is not
overridden. But does this mean that if a default template supplies a
element, and a field does not, but supplies other child
elements, the behavior disappears? (Personally, I think the
answer should be no, but there should also be some way to cancel the
behavior.)

Also, I’ve been writing my code with the understanding that there are
default templates for each class, which are overridden by the default
templates in the CSL file, which are overridden by specific elements. Is
this a valid way of handling things? If so, can we codify, in CSL, the
default templates for each class in order to ensure consistency across
implementations? I’m willing to take a shot at it, but Bruce may know more.

Thanks,
Simon

2

Currently, the CSL schema defines inheritance as follows:

Base fields, many of which are compound. The override logic is that

if there is a child of a field other than cs:substitute, then the

default template is overridden. Otherwise, fields inherit from their

default definitions.

This means that if a default template specifies child elements, and a field
specifies only a element, the default template is not
overridden.

Correct.

But does this mean that if a default template supplies a
element, and a field does not, but supplies other child
elements, the behavior disappears? (Personally, I think the
answer should be no, but there should also be some way to cancel the
behavior.)

Hmm … good question. I have been assuming the sustitute behavior
basically cannot be cancelled. They’d be commonly used for authors and
for dates. Can you imagine a circumstance where one would want to
cancel that?

Also, I’ve been writing my code with the understanding that there are
default templates for each class, which are overridden by the default
templates in the CSL file, which are overridden by specific elements. Is
this a valid way of handling things?

I think it is, though is difficult for things like publishers.

But certainly author templates and subsittution might have some
default bhavior (not sure about roles though).

If so, can we codify, in CSL, the
default templates for each class in order to ensure consistency across
implementations? I’m willing to take a shot at it, but Bruce may know more.

I’m fine with doing this if it works well. Forcing defaults isn’t a
bad alternative.

One option might be to move some stuff (role? substitution?) out of
the top-level detaults into their own structures so the defaulting and
override is perhaps cleaner.

Tell you what: I’m working on trying to finish an article. Why don’t
you take your shot at it, and let me know. I still need to deal with
the stuff from the other day.

Bruce