[osis-core] <hi> types

[Todd Tillinghast]

Chris,

> 
> 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.

Agreed.

> 
> > 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.

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
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.

Agreed.

> 
> --Chris
> 
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core