[osis-core] OTCite: final call
Scribe
osis-core@bibletechnologieswg.org
Mon, 20 Oct 2003 13:36:53 -0700 (MST)
Guys,
I understand and respect the idealistic argument for 'pay
attention to the pickin' attribute value and you'll get it right'.
I also know that we are a very practicle group seen, for instance,
by our catering to the provide 'levels' of OSIS compliance.
Like the group, while I agree that people should pay attention to
all attributes and should be 100% OSIS compliant, I also know that they
will not all start there.
Rendering all <note>'s the same, <title>'s the same, even <q>'s
(currently, just possibly ignoring the 'block' type) the same, gives a
basic, OSIS conformance that I believe should probably be good 'level'
distinction.
My point is not to disagree that <q type="otCite"> would be
acceptable in a perfect world. Just that the PRACTICLE result of someone
not paying attention to the attribute will render misleading and confusing
information to the user.
I also liked Chris' point (obviously because it gives concession
to a solution I favour), that although we have <name>, we have given
<divineName> for a case that happens just so much in our target text its
frequency alone might have warranted it.
-Troy.
On Mon, 20 Oct 2003, Todd Tillinghast wrote:
> Patrick,
>
> I believe that we need to provide an authorized mechanism for this issue
> (Troy should not be forced to use <seg>).
>
> Despite Troy's earlier conclusion that all <q> elements would be
> rendered with a quotation mark ("), I content this is not true (Chris
> posted a similar sentiment).
>
> There a number of elements that could be separate elements but are
> distinguished by the type attribute. Following are a few examples:
> <div type="book"> <book>
> <div type="section"> <section>
> <q type="block"> <blockQuote>
> <hi type="bold"> <b>
>
> As with any endorsed "type" values I would expect the user of the text
> to consider the special/additional meaning the type attribute assigns to
> the element. In the case of <q type="block"> a special rendering would
> usually be expected and would not necessarily include quotation markers.
>
> Based on the above logic I propose <q type="cite"> or <q type="OTCite">.
>
> Todd
>
> > -----Original Message-----
> > From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> > admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> > Sent: Monday, October 20, 2003 7:27 AM
> > To: osis-core@bibletechnologieswg.org
> > Subject: [osis-core] OTCite: final call
> >
> > Greetings!
> >
> > Had an interesting conversation with Troy yesterday on the problem of
> > text in the NT that is not a quotation in the modern sense of word for
> > word reporting of a passage but is in the opinion of the translator, a
> > paraphrase of an OT text. The goal is to encode those words so that
> they
> > can be selected for distinct rendering. (A note could be supplied with
> > an osisRef with string range to specify the passage but that would be
> > more complicated than the <q> solution with an attribute.)
> >
> > For those who are interested, TEI dealt with the similar problem with
> an
> > <interp> element that used a to and from attribute to record similar
> > information.
> >
> > Note that the <cite> element in XHTML is inappropriate as the spec
> > equates reference and cite as in making a reference to the title of a
> > work, or in the words of the standard:
> >
> > > The cite element contains a citation or a reference to other
> sources.
> >
> > I don't read "other sources" as being a paraphrase.
> >
> > To be used in the OT context, <cite> would be more appropriate for:
> >
> > Numbers 21
> >
> > 14 Therefore it is said in the book of the <cite>Wars of
> Yahweh</cite>,
> > Vaheb in Suphah, The valleys of the Arnon,
> >
> > Assuming we interpret, Wars of Yahweh, to be the actual title, I would
> > mark the quote as starting at the end of the <cite> element but I am
> not
> > certain that I would agree with the RSV's ending of the quotation
> (that
> > is how it is marked in typography) at the end of verse 15.
> >
> > Still, I agree with Troy that it is a problem that we don't have a
> good
> > mechanism to deal with at the moment.
> >
> > On the other hand, I am extremely reluctant to add a new element and
> > content model to deal with this admittedly important issue.
> >
> > At present Troy is marking these with <seg> which does avoid default
> > rendering for <q> from rendering these passages as quotes. That
> solution
> > still requires processing of the attribute for rendering but does
> avoid
> > any default formatting based upon the material being in a <q> element.
> >
> > My preference would be to specify levels of OSIS conformant processing
> > and say that you have to take attributes into account for a particular
> > level of OSIS processing. That would allow the use of our <q> element
> > for these passages with an attribute to specify that it is not a quote
> > in the modern sense.
> >
> > Troy resists that solution and I think at this point the best option
> we
> > can offer is for him to continue to use <seg> as he does now. I don't
> > really think attribute based processing is all that problematic (I
> > appreciate the Lockman editor's concern but think it is misplaced) but
> > then I don't mind attribute based grammars either, so my judgment in
> > that regard may be suspect.
> >
> > Comments?
> >
> > Hope everyone is at the start of a great week!
> >
> > Patrick
> >
> > --
> > Patrick Durusau
> > Director of Research and Development
> > Society of Biblical Literature
> > Patrick.Durusau@sbl-site.org
> > Chair, V1 - Text Processing: Office and Publishing Systems Interface
> > Co-Editor, ISO 13250, Topic Maps -- Reference Model
> >
> > Topic Maps: Human, not artificial, intelligence at work!
> >
> >
> > _______________________________________________
> > osis-core mailing list
> > osis-core@bibletechnologieswg.org
> > http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
>
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
>