I just went over my substitution code once again today. To refresh
everyone’s memories, the issue is that when a title is substituted for an
author, depending on the type of resource, the title should be italicized,
in quotes, or otherwise formatted differently.
My current solution is to take the first title element from the item style
with the same container attribute as the substitute, and use that element’s
style for the substitute’s style. E.g., if I have:
And:
Then I can correctly italicize the title when it substitutes for the author
for the ³book² item type, while leaving it alone for ³article,² etc. This is
not the simplest rule (nor the simplest thing to code), but it works fine
for bibliography entries. Unfortunately, it doesn’t work so well for
citations, which are often formatted differently from the bibliography entry
(quotes around titles, etc.).
Thinking it over, it seems the simplest way to resolve this problem is to
add a way of specifying different substitutions for different item types.
Then, in the citation section, we¹d define the author as:
Not exactly concise, especially since we still need to define a separate
element in the section, but I¹m not sure if there¹s
a better way of handling it. An alternative would be some kind of if/else
construct, but that would require just as much XML (and more if the chapter
is cited differently from the article). Note that the current schema has
as a sub-element of , but I¹m not exactly sure what
purpose it serves; this example uses for a completely different
reason.
If we go with this approach, I could also optionally ditch my current
solution, which would simplify implementation.
Simon
[…]
Thinking it over, it seems the simplest way to resolve this problem is
to add a way of specifying different substitutions for different item
types. Then, in the citation section, we’d define the author as:
Not exactly concise, especially since we still need to define a
separate element in the section, but I’m not
sure if there’s a better way of handling it. An alternative would be
some kind of if/else construct, but that would require just as much
XML (and more if the chapter is cited differently from the article).
Not necessarily. You could do something like XSLT:
<if test="type='book'">...</if>
<else>...</else>
Note that the current schema has as a sub-element of
, but I’m not exactly sure what purpose it serves; this
example uses for a completely different reason.
It’s there to distinguish from standard templates, where all children
get applied. I don’t see how what you are doing here is any different;
just that the criterion for the choice is different (type, rather than
property).
OTOH, if you want to define a rule that says “the content of
cs:substitute is a choice list” that might work?
If we go with this approach, I could also optionally ditch my current
solution, which would simplify implementation.
And if we don’t go with this solution, stuff doesn’t get formatted
right?
I hate to have to introduce this more complicated stuff if not needed,
but it seems like it is.
What’s your preferred solution given the above?
Bruce
Not necessarily. You could do something like XSLT:
…
…
Unless you’re particularly wedded to the idea of making it look like XSLT,
I’d suggest that:
…
Is easier to parse and simpler for authors.
Note that the current schema has as a sub-element of
, but I¹m not exactly sure what purpose it serves; this
example uses for a completely different reason.
It’s there to distinguish from standard templates, where all children
get applied. I don’t see how what you are doing here is any different;
just that the criterion for the choice is different (type, rather than
property).
OTOH, if you want to define a rule that says “the content of
cs:substitute is a choice list” that might work?
cs:substitute is already different from all other sub-elements in its
inheritance rules. I think requiring the sub-element is probably
less intuitive than putting all the elements in without any
wrapper. (In fact, while designing styles, I often forgot the
wrapper. A validator will catch this, but not everyone who wants to design
or modify a style will have a validator.) It seems to make more sense in
conjunction with type than with a simple list of properties.
If we go with this approach, I could also optionally ditch my current
solution, which would simplify implementation.
And if we don’t go with this solution, stuff doesn’t get formatted
right?
If we don’t go with this solution, either the citation entries for
author-less books (dictionaries, etc.) will be formatted improperly, or the
styles would need to be long and repetitive.
I hate to have to introduce this more complicated stuff if not needed,
but it seems like it is.
What’s your preferred solution given the above?
Either the / or the solutions would be fine with me. Both
are about equally easy to implement in JavaScript.
Simon
Unless you’re particularly wedded to the idea of making it look like
XSLT,
I’d suggest that:
…
Is easier to parse and simpler for authors.
I thought about that. But are there other conditionals than type?
cs:substitute is already different from all other sub-elements in its
inheritance rules. I think requiring the sub-element is
probably
less intuitive than putting all the elements in without
any
wrapper.
OK, so how should choose be defined, and where should it be allowed?
Right now, for example, it’s also a child of the layout/item element.
Bruce
Unless you’re particularly wedded to the idea of making it look like
XSLT,
I’d suggest that:
…
Is easier to parse and simpler for authors.
I thought about that. But are there other conditionals than type?
Well, there are field conditionals (e.g., does the “contributor” field
exist) but I don’t see why you’d need them in substitution. If you wanted to
generalize things, and make an extended field (much like ), I
still think that:
element cs:if { (attribute type { text } | attribute field { text }) }
Is the better option. Since the publication title is , it might make sense to add cs-relation, too. And,
obviously, we’d also want to enumerate the options for type and field rather
than simply leaving them as free text.
In this situation, it might make sense to add some kind of wrapper around
the and elements, since it would make parsing easier (for me, at
least). We could also nest inside , but I don’t know how I feel
about that.
cs:substitute is already different from all other sub-elements in its
inheritance rules. I think requiring the sub-element is
probably
less intuitive than putting all the elements in without
any
wrapper.
OK, so how should choose be defined, and where should it be allowed?
Right now, for example, it’s also a child of the layout/item element.
I think it’s fine the way it is as a child of the layout/item element, but
not necessary (and perhaps even confusing) as a child of substitute. The
only two possible sub-elements of are and , and
there’s no reason (as far as I can tell) that is necessary, since,
under the current schema, would produce the same
behavior. After that simplification, we’d have only one sub-element, which
makes little sense to me, so why not get rid of ?
Simon
Well, there are field conditionals (e.g., does the “contributor” field
exist) but I don’t see why you’d need them in substitution. If you wanted to
generalize things, and make an extended field (much like ), I
still think that:
element cs:if { (attribute type { text } | attribute field { text }) }
Is the better option. Since the publication title is , it might make sense to add cs-relation, too.
One (little?) problem with this is that a type is defined by a string,
while a field by a namespaced element.
Do we care?
In this situation, it might make sense to add some kind of wrapper around
the and elements, since it would make parsing easier (for me, at
least).
Suggestions? Choose?
Bruce
One (little?) problem with this is that a type is defined by a string,
while a field by a namespaced element.
Do we care?
Ick. We could list all of the fields as possible strings in the schema
(annoying if you have to add/delete one), we could define it as text and
recognize that the validator won’t pick it up if it’s wrong, or:
I think I’d prefer one of the former approaches, because they’re simpler and
more concise, although the latter is arguably more extensible.
It also occurs to me we might want an tag, because, while it’s
certainly possible to do:
It looks much nicer as:
In this situation, it might make sense to add some kind of wrapper around
the and elements, since it would make parsing easier (for me, at
least).
Suggestions? Choose?
I’d say , because / really is different from .
Simon
I’m fine with the condition and the else-if, but am a little uneasy
about the specifics above (not just a question of extensibility, but
correctness). Will think on this some more later.
Bruce