[osis-core] <hi> types
Chris Little
osis-core@bibletechnologieswg.org
Mon, 18 Aug 2003 12:03:53 -0700 (MST)
Todd,
> I am concerned that encoders using would use the presentation related
> elements RATHER THAN other elements. (Ex <hi type='smallCaps'>Lord</hi>
> rather than <divineName type='yhwh'>Lord</divineName>, etc...)
This is the same situation as with the <foreign>/<hi> case Patrick
mentioned. I think people should be ABLE to do this, but chided harshly
if they ever choose to do so. In other words, I think it should be
describe via best practices that this is absolutely not how we intend
things to be encoded.
> I do see a need for <hi> in non-Biblical texts. If as Chris suggests we
> use <hi> to encode meaning and not presentation we will be better off.
> I would like to say away from type values of bold, italics, etc... in
> favor of strongEmphasis, emphasis, etc... I don't have a good
> suggestions for a comprehensive set of a type values.
I see <hi> as useful for describing original document presentation. With
that in mind, I think common terms like bold & italics are what we should
use, because they are what we mean. We can change them to other names,
but the purpose of doing so is essentially just to avoid using the name
everyone is thinking (and can easily remember) of because they have
associations with presentation markup. If you're describing presentation
because either, that's what's important about the document or you're
incapable of discerning the semantics behind presentation, I think you
should just use presentation terms.
> Along the same lines we may want to think about the fact that a single
> <hi> element may need to carry the meaning ascribed by more than one
> type value. Do we provide only a single type value, provide more than
> one attribute on <hi>, or do we allow the type attribute on <hi> to be a
> list? Thoughts?
If you want bold-italic, I think you should just nest one inside of the
other. It's a simple implementation, though providing combinations of all
possible values might be a better solution.
> If we are in consensus related to add a <hi> element does it make sense
> to create an internal schema release that adds in <hi> for use in
> encoding the sample documents?
<hi> has been part of the schema since 1.0, I believe (and with these
semantics, generally). I'm just recommending that we give it some
standard types. I think the attribute extension mechanism is sufficient
for samples.
--Chris