[tei-council] bibliog doc
mholmes at uvic.ca
Fri May 14 11:10:41 EDT 2010
On 10-05-14 02:38 AM, Lou wrote:
>> It's easy enough to create a<biblStruct> for this, but it's extremely
>> hard for generic XSLT to detect what kind of item it is, determine what
>> kind of formatting it should be given based on that, and then compensate
>> for the missing author in the rendering.
> Well that rather depends on how "generic" you "generic XSLT" is seems to
> me. FWIW you have @type attribute on biblStruct which you might for
> example set automatically by the absence of an<author>, if that's the
> issue that's bedevilling your stylesheet!
That's precisely my point: you need to do something like this:
and then you have
and end up with sixty-odd templates for each style guide.* I've been
down this road at least three times in three different projects, and
believe me, it's not easy, especially when the rendering requirements
are rigorous -- such as in the case of formal print publications, when
you must get everything absolutely right, or face an enraged editor.
Also, in this particular example, how in <biblStruct> do you handle the
fact that a <title level="m"> is part of another <monogr>? Do you have
the two <title> elements in one <monogr>, or do you have the first title
> With<bibl>, it's easy --
>> encode all the elements in the order they need to come out, and you're done.
> As I remarked elsewhere the trouble with this approach is that "the
> order they need to come out" may not be the same the next time you want
> to process this<bibl> using some other application....
I know, but it's no harder to process a <bibl> than a <biblStruct>, so
with <bibl> you get one free easy rendering and all the rest are hard;
whereas with <biblStruct>, every rendering is hard. And in real life
projects, we often only need to output one style guide.
My main concern here is that the vast majority of examples in this
section show <biblStruct>s. That's because <biblStruct>s are harder and
need more explanation; but it gives the impression that they're somehow
better than <bibl>s and to be preferred. This would lead most people to
believe that they should really use <biblStruct>s if they can, and in
many cases this would be the wrong decision -- especially, in my view,
when your encoding as part of a publishing workflow.
* You could also do this kind of thing:
<xsl:when test="not(analytic/author) and not(analytic/editor)">
and so on, which reduces the number of templates but makes each one much
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
Half-Baked Software, Inc.
(mholmes at halfbakedsoftware.com)
martin at mholmes.com
More information about the tei-council