Simon,
How do you want to proceed on the schema?
Perhaps the cleanest approach is to work with the branch schema and copy
over attributes and other structures from the trunk as you need them? I
started to do this with, for example, the parameters for names and such.
As I mentioned, using oXygen would be ideal, as you can have the schema
open in one window (complete with validation and indentation support)
and a test style that gets validated against it in another.
Some other thoughts:
I moved to the cs:context element because I thought we needed contexts
other than citation and bibliography.
If in fact we’re doing that with other methods, then we probably ought
to switch back to cs:citation and cs:bibliography, just so that we are
ensured it will be possible to validate stuff.
This brings up the question of whether to maintain the tight class-based
validation constraints of the trunk schema? That is there in part for
documentation reasons, but also to alert people to when they’re doing
something obviously wrong.
Bruce
Simon,
How do you want to proceed on the schema?
Perhaps the cleanest approach is to work with the branch schema and
copy
over attributes and other structures from the trunk as you need
them? I
started to do this with, for example, the parameters for names and
such.
This makes sense to me.
As I mentioned, using oXygen would be ideal, as you can have the
schema
open in one window (complete with validation and indentation support)
and a test style that gets validated against it in another.
Some other thoughts:
I moved to the cs:context element because I thought we needed contexts
other than citation and bibliography.
If in fact we’re doing that with other methods, then we probably ought
to switch back to cs:citation and cs:bibliography, just so that we are
ensured it will be possible to validate stuff.
Either way. The allowed child elements should be the same for both,
so I’m not sure where the validation issue comes in.
This brings up the question of whether to maintain the tight class-
based
validation constraints of the trunk schema? That is there in part for
documentation reasons, but also to alert people to when they’re doing
something obviously wrong.
I would say no. Some of the current Zotero styles don’t validate
because of these constraints, I think, but there’s nothing obviously
wrong with them. Versatility is preferable to strict validation. It
might make sense to have a tool that ensures there’s nothing
obviously wrong with them, but I don’t think this logic has to be
embedded in the schema.
Do we actually need style classes? From the parser’s point of view,
it seems like the only difference is between note citations and in-
text citations.
Simon
If in fact we’re doing that with other methods, then we probably ought
to switch back to cs:citation and cs:bibliography, just so that we are
ensured it will be possible to validate stuff.
Either way. The allowed child elements should be the same for both,
so I’m not sure where the validation issue comes in.
In general, it’s harder to validate patterns based on attributes than
elements. In XSD you can’t do it at all. In RNG, you can, but there are
some cases where you can’t. For example, IIRC, the interleave pattern
(unordered constraints) cannot be based on an attribute.
E.g. it’s a question of technical limitations more than anything. Am
not sure it’d be a problem; just observing it can be.
This brings up the question of whether to maintain the tight class-
based
validation constraints of the trunk schema? That is there in part for
documentation reasons, but also to alert people to when they’re doing
something obviously wrong.
I would say no. Some of the current Zotero styles don’t validate
because of these constraints, I think, but there’s nothing obviously
wrong with them. Versatility is preferable to strict validation. It
might make sense to have a tool that ensures there’s nothing
obviously wrong with them, but I don’t think this logic has to be
embedded in the schema.
Yes, but there’s a lot of gray area in between. If the schema is too
tight now, does that mean it should be wide-open?
Do we actually need style classes? From the parser’s point of view,
it seems like the only difference is between note citations and in-
text citations.
Well, we could tweak the schema to make sure everything is explicit.
For example, right now disambiguation of author-date styles (Doe,
1999a, 1999b) is implicit; understood to be a characteristic of the
class. The same with the “author” class.
Class-based validation also allows you to control:
- allowed sort options
- whether a citation and bibliography element are both required
- what should be in a citation
Bruce
If in fact we’re doing that with other methods, then we probably
ought
to switch back to cs:citation and cs:bibliography, just so that
we are
ensured it will be possible to validate stuff.
Either way. The allowed child elements should be the same for both,
so I’m not sure where the validation issue comes in.
In general, it’s harder to validate patterns based on attributes than
elements. In XSD you can’t do it at all. In RNG, you can, but there
are
some cases where you can’t. For example, IIRC, the interleave pattern
(unordered constraints) cannot be based on an attribute.
E.g. it’s a question of technical limitations more than anything. Am
not sure it’d be a problem; just observing it can be.
But unless we want stricter validation as below, there’s not much
need to validate patterns based on attributes. The only difference
between the bibliography and citation contexts would be allowed options.
This brings up the question of whether to maintain the tight class-
based
validation constraints of the trunk schema? That is there in part
for
documentation reasons, but also to alert people to when they’re
doing
something obviously wrong.
I would say no. Some of the current Zotero styles don’t validate
because of these constraints, I think, but there’s nothing obviously
wrong with them. Versatility is preferable to strict validation. It
might make sense to have a tool that ensures there’s nothing
obviously wrong with them, but I don’t think this logic has to be
embedded in the schema.
Yes, but there’s a lot of gray area in between. If the schema is too
tight now, does that mean it should be wide-open?
Do we actually need style classes? From the parser’s point of view,
it seems like the only difference is between note citations and in-
text citations.
Well, we could tweak the schema to make sure everything is explicit.
For example, right now disambiguation of author-date styles (Doe,
1999a, 1999b) is implicit; understood to be a characteristic of the
class. The same with the “author” class.
Class-based validation also allows you to control:
- allowed sort options
- whether a citation and bibliography element are both required
- what should be in a citation
Validation should serve to ensure that any CSL style is interpreted
in the same way by any CSL parser. I believe that, when possible,
things like disambiguation should be explicit in the style. (EndNote
provides four options for controlling disambiguation. While this
might be overkill, it wouldn’t hurt.) I certainly don’t think we want
to get into specifying what is allowed in a citation. A parser should
be able to handle any permutation of elements, and that’s all that
matters.
Simon
Simon Kornblith wrote:
Validation should serve to ensure that any CSL style is interpreted
in the same way by any CSL parser.
Fine. In any case, it’d be better than people just guessing whether it’s
valid. Zotero, for example, should not accept invalid files.
I believe that, when possible,
things like disambiguation should be explicit in the style. (EndNote
provides four options for controlling disambiguation. While this
might be overkill, it wouldn’t hurt.)
So what should the options be here?
year-suffix
title
…?
Bruce
EndNote provides the following:
"Include the author initials or full name in citation"
Name Format: {“Full Names” | “A.B.” | “AB” (etc)}
“Add more authors until the citation is unique”
"Add the title for different works by the same author"
Title Format: {“Full Title” | “Short Title”}
"Add a letter after the year"
Letter Format: {“2000a, b” | “2000a, 2000b”}
Simon
Simon Kornblith wrote:
EndNote provides the following:
“Include the author initials or full name in citation”
Name Format: {“Full Names” | “A.B.” | “AB” (etc)}
“Add more authors until the citation is unique”
“Add the title for different works by the same author”
Title Format: {“Full Title” | “Short Title”}
“Add a letter after the year”
Letter Format: {“2000a, b” | “2000a, 2000b”}
Those aren’t mutually exclusive, are they? I mean, certainly the last
two are, but not sure about those and the first two.
Bruce
No. In EndNote, these are all checkboxes.
Simon
So a strawman:
disambiguate-citation = element cs:option {
attribute name { “disambiguate-citation” },
attribute value { “year-suffix” | “title-full” | “title-short” }
}
disambiguate-citation-names = element cs:option {
attribute name { “disambiguate-citation-names” },
# first option modifies indivual names, and second extends et-al "use-first"
attribute value { “add-givenname” | “add-names” }
}
Bruce
These aren’t mutually exclusive either, are they?
Simon