OK:------------------------------------------------------------------------
r310 | bdarcus | 2007-07-07 12:28:53 -0400 (Sat, 07 Jul 2007) | 1 line
reverted back to previous version of branch schema
So here’s what I’m looking at:
agent =
element cs:agent {
attribute name { cs-agents },
(cs-names & cs-label?)
}
date =
element cs:date {
attribute name { cs-dates },
(cs-date-year? & cs-date-month? & cs-date-day?)
}
So I’m thinking agent makes sense, but that event is better as date.
I’m also wondering given the general switch to using attributes more if
we don’t do:
cs-date-year =
element cs:date-part {
attribute name { “year” },
formatting
}
Result would be:
Or:
One question, though, is whether a date element needs a variable
attribute? For sake of argument, what if I wanted to do:
Should that be legal? Is there a better way to achieve the same thing?
Thoughts on any of this?
Bruce
So here’s what I’m looking at:
agent =
element cs:agent {
attribute name { cs-agents },
(cs-names & cs-label?)
}
date =
element cs:date {
attribute name { cs-dates },
(cs-date-year? & cs-date-month? & cs-date-day?)
}
So I’m thinking agent makes sense, but that event is better as date.
I agree.
I’m also wondering given the general switch to using attributes
more if
we don’t do:
cs-date-year =
element cs:date-part {
attribute name { “year” },
formatting
}
I was wondering about this myself.
Simon Kornblith wrote:
…
I’m also wondering given the general switch to using attributes
more if
we don’t do:
cs-date-year =
element cs:date-part {
attribute name { “year” },
formatting
}
I was wondering about this myself. On one hand, this might make the
schema a little more complicated (given month needs a different set
of allowable forms than year, etc.), but on the other hand, it does
seem more logical.
Well, it’s no more complicated than the current approach of separate
elements even if we want different validation patterns for each
(something you can’t do in XSD, BTW, but that’s never stopped me from
exploiting it in RNG).
[…]
One question, though, is whether a date element needs a variable
attribute? For sake of argument, what if I wanted to do:
We need to differentiate between date accessed and date published, at
the very least. We could make the default date (which, for
most item types, would be the date published, although, for example,
patents have separate application and issue dates), then allow for access date. Not quite sure how best to
handle this.
What I’m trying to get at here is that there might be two different
kinds of uses for macros: variable-specific (“I have an event date, do
x”), and what I guess I’ll call presentation-specific (“I have a date, I
want to print just the year”).
Allowing the second would require some logic which essentially passes a
parameter from the calling cs:text element. I’ve been experimenting with
this in ways that get at your idea for a notion of a default:
element cs:date {
The variable attribute should generally be specified, but may be
omitted when in the context of macro. In that case, the variable
must be passed by the calling cs:text element. One can also specify
a default-variable that may be overridden if specified on the
calling template.
(attribute variable { cs-date-tokens }
> attribute default-variable { cs-date-tokens })?,
date-part+
}
I guess I lean towards not allowing this on second thought, though,
because I’m not sure the greater potential terseness is worth the added
implementation (and style, and schema) complexity.
Bruce
Simon Kornblith wrote:
So I’m thinking agent makes sense, but that event is better as date.
I agree.
Actually, thinking some more, I wonder if your earlier “names” structure
makes more sense?
Reason: at first I was wanting to think of the main element structures
in terms of the data. But I think that might be wrong: that they’re
really about how to handle presenting data-types (date, string, etc.).
So if we have:
text (simple string data variables and macro results)
term (localized string variables)
label (localized string variables; hmm, how is this different?)
date (date data variables)
Then we would say:
names (lists of structured agent name data)
… or something like that.
Does this make sense? Any suggestions on clarifying the model here?
Bruce
Oh, and just to be clear, I’m happy to stick with cs:agent if it does
make more sense.
Bruce
Yes, this makes sense. In fact, I had originally thought of a type-
centric model when I created my sample APA style. I don’t really have
any opinion on “agent” vs “names,” since it’s really just a matter of
tag name.
One issue I believe we have yet to address: what do we do about
generic locators? In Zotero, for example, I can cite a page, a
paragraph, or a line. How does this get translated into the style?
One option is to use and (or something to that effect). Another is to
selectively populate either the page, paragraph, or line variable. In
this case, we would either need , or would have to
take on a plural form if the corresponding variable is plural (e.g.,
pp. 45-67 but p. 45).
I think I favor selectively populating page/paragraph/line, because
some styles may use no label when referring to pages, but do use a
label when referring to paragraphs or lines. What do you think?
Simon
Simon Kornblith wrote:
I think I favor selectively populating page/paragraph/line, because
some styles may use no label when referring to pages, but do use a
label when referring to paragraphs or lines. What do you think?
How about testing with a few examples. And let’s make it a little hard;
how about “page 45, line 3”?
Might be worth thinking about using a macro with a conditional?
Bruce
Since, as is currently configured, the contents aren’t
printed unless they contain something besides a
entry (a rule that I think makes sense, although if it’s too
counterintuitive we could use conditionals), this should suffice,
assuming is automatically
pluralized when necessary.
Simon
Simon Kornblith wrote:
Since, as is currently configured, the contents aren’t
printed unless they contain something besides a
entry (a rule that I think makes sense, although if it’s too
counterintuitive we could use conditionals),
How much more verbose would the syntax get if we required using choose?
… this should suffice,
assuming is automatically
pluralized when necessary.
Seems fine. A few details:
- probably “term-name” should be just “term”
- the variable values should include a “cited” prefix (“cited-pages”,
“cited-paragraphs”, etc.)
- we should avoid the “|” syntax and keep it consistent with the choose
structure
Bruce
Simon Kornblith wrote:
Since, as is currently configured, the contents aren’t
printed unless they contain something besides a
entry (a rule that I think makes sense, although if it’s too
counterintuitive we could use conditionals),
How much more verbose would the syntax get if we required using
choose?
This also changes other parts of the schema. Including the above, the
APA schema would end up being around 14-18 lines longer. I can’t come
up with any logical reason that a term that should always be printed
would be placed in a element.
… this should suffice,
assuming is automatically
pluralized when necessary.
Seems fine. A few details:
- probably “term-name” should be just “term”
OK.
- the variable values should include a “cited” prefix (“cited-pages”,
“cited-paragraphs”, etc.)
Hmm. This brings up a possible issue: if we have both “pages” and
“cited-pages” (or “page” and “cited-page”), if, for example, citing a
single page from a chapter in a book, one might be plural while the
other is singular. Thus, we need either <label variable=“cited-page”/
or to control if
the term is singular or plural.
- we should avoid the “|” syntax and keep it consistent with the
choose
structure
This was just for illustrating the possible options, not something I
ever intended to end up in the schema.
Simon
Simon Kornblith wrote:
How much more verbose would the syntax get if we required using
choose?
This also changes other parts of the schema. Including the above, the
APA schema would end up being around 14-18 lines longer. I can’t come
up with any logical reason that a term that should always be printed
would be placed in a element.
The original purpose of group was where you need rendering like:
(New York:Routledge)
So in that case the issue isn’t the term text, but rather the prefix and
suffix punctuation.
I’m agnostic on the question you raised, but I don’t find the implicit
rule you noted confusing.
… this should suffice,
assuming is automatically
pluralized when necessary.
Seems fine. A few details:
- probably “term-name” should be just “term”
OK.
- the variable values should include a “cited” prefix (“cited-pages”,
“cited-paragraphs”, etc.)
Hmm. This brings up a possible issue: if we have both “pages” and
“cited-pages” (or “page” and “cited-page”), if, for example, citing a
single page from a chapter in a book, one might be plural while the
other is singular.
It is correct that a user may be citing either singular or plural.
Consider quotes that span pages.
Thus, we need either <label variable=“cited-page”/
or to control if
the term is singular or plural.
The “page” term already has within it the logic to handle either case.
The issue, I guess, is the same as when we deal with non-creator
contributors.
So perhaps we do use cs:label for both cases??
How would we define “label” in the documentation then?
Bruce
“label” specifies a term that depends on a variable. As a sub-element
of , its format depends on the variable to which the
element applies. As an independent element, the variable to which it
applies must be specified explicitly.
Sound good?
Simon
Simon Kornblith wrote:
The “page” term already has within it the logic to handle either case.
The issue, I guess, is the same as when we deal with non-creator
contributors.
So perhaps we do use cs:label for both cases??
How would we define “label” in the documentation then?
“label” specifies a term that depends on a variable. As a sub-element
of , its format depends on the variable to which the
element applies. As an independent element, the variable to which it
applies must be specified explicitly.
Sound good?
Yes, but from the XML tree perspective, you could as well as say:
The variable on which the format depends can either be specified on the
current node, or on its parent.
Or something like that. The idea from an abstract processing perspective
is you first look at the node proper, and then if not present to the
parent node.
Right?
Bruce
Well, actually, not the parent node; the more general “ancestor node”.
Bruce