[osis-core] <hi> types
Mon, 18 Aug 2003 13:19:12 -0600
> > I am concerned that encoders using would use the presentation
> > elements RATHER THAN other elements. (Ex <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
> 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
> > use <hi> to encode meaning and not presentation we will be better
> > I would like to say away from type values of bold, italics, etc...
> > 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.
> that in mind, I think common terms like bold & italics are what we
> use, because they are what we mean. We can change them to other
> but the purpose of doing so is essentially just to avoid using the
> everyone is thinking (and can easily remember) of because they have
> associations with presentation markup. If you're describing
> 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.
Hmm... I agree related to encoding the exact presentation for 'ancient
texts' BUT I see a real problem for more modern encodings. I would
rather see people encode <someElementName type='keyPoint'>key point
text</someElementName> rather than <hi type='bold'>key point text</hi>.
I am not sure what the 'someElementName' should be.
Do you think it makes sense to have an ancient text schema extension?
At least we may want to establish an ancient text best practice and
possibly a not-ancient text best practice.
> > Along the same lines we may want to think about the fact that a
> > <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
> > one attribute on <hi>, or do we allow the type attribute on <hi> to
> > list? Thoughts?
> If you want bold-italic, I think you should just nest one inside of
> other. It's a simple implementation, though providing combinations of
> possible values might be a better solution.
> > If we are in consensus related to add a <hi> element does it make
> > 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
> for samples.
> osis-core mailing list