Add new quote specific milestone attributes - RE: [osis-core] milestone name inconsistencies

Patrick Durusau osis-core@bibletechnologieswg.org
Sat, 16 Nov 2002 15:46:26 -0500


Troy,

Troy A. Griffitts wrote:

>>> I have to strongly disagree with the use of osisID to match up start 
>>> and
>>> end milestones. 
>>
>>
>> On what basis? The only reason TEI does not use ID for that purpose 
>> is that it has to be unique in the document.
>
>
> Patrick, sorry, but I agree 100% with Todd on this one.  We don't use 
> osisID to match segmented tags either.  We use splitID.  Forcing an 
> osisID causes there to be unwanted symbols in the text.

Too late! Todd, that silver-tongued devil has argued me into adding 
start/end to the <qStart>, <qEnd> milestones. We did not discuss 
milestoneStart and milestoneEnd. Should I add them there as well or just 
just splitID? Or should I use splitID on both? (Would avoid adding 
attributes at all. Just some prose.)

Todd: What about splitID? As opposed to start/end?


>
> If Harry gets his way when we add the mechanism for defining 
> versification schemes, we will USE A REGULAR OSIS DOCUMENT to do such. 
> This would mean all kinds of extra anchors, just because we had to add 
> them for matching milestones.
>
> We have 2 very different purposes here.  I don't see any convincing 
> reason to use the same attribute for both of these purposes.  If you 
> want to avoid adding a new attribute, I think splitID is much more 
> similar to what we want to do with matching tags.  I would recommend 
> using splitID for this purpose or adding a new attribute.
>
> I too thought the old milestone_SE was for matching the start/end.
>
> I still don't get the pt and se.  I think I understand your 
> explanation, but have never heard that before, never remember 
> discussing it, and really think it is out-of-theme from the rest of 
> the schema.
>
> I would still argue that the mere fact that we HAVE an enumerated list 
> of milestone types designates a PROBLEM.  None of these types has any 
> special attributes, and I'm sure they should have.  This is the same 
> problem we have with <q> and will have with all other "generic 
> milestone"-type markup.  If a tag can be used as a milestone, then let 
> IT be used as a milestone, or else provide a new tag with all the same 
> attributes and behaviour.

Steve: comments?

>
> <q who="Patrick">in weariness and toil, in sleeplessness often, in 
> hunger and thirst, in fastings often, in cold and nakedness -- besides 
> all the other things, what comes upon me daily: my deep concern for 
> all the osis-core members</q>
> Oh wait, that's Paul-- almost.

;-), yes, almost. ;-)

Patrick

>
>     -Troy.
>
>
>
>
>>
>> Any mechanism is going to have to involve either pointing, whether 
>> expressed as a ref or not, or have some sort of matching tokens.
>>
>>>
>>> If PT if for presentation type and SE is for Something Else AND neither
>>> is to help us match up starting and ending milestones then we need
>>> ANOTHER attribute for the purpose of matching up milestones.
>>>
>>> We must NOT use osisID to match up milestones starting and endings
>>> because we would force the inclusion of arbitrary trash in the
>>> identifier namespace whose sole purpose is to match up milestones. 
>>> If the encoder wants to create an osisID for a milestone let them 
>>> but it
>>> should not be required so that a pair can be matched up.
>>>
>>> We should have some thing like:
>>> <p>
>>>     <qStart end="xyz"/> text <qEnd start="xyz"/>
>>> </p>
>>>
>>> If the "end" and "start" attributes are not required what good are 
>>> start
>>> and end milestones.
>>>
>> What good are the paired milestones anyway? As I recall there were 
>> many calls for pseudo-containment milestones, which I personally 
>> disagree with but now we have those and paired <qStart>, <qEnd> 
>> milestones.
>>
>> I am really at a loss to explain why we should require end/start on 
>> matching milestones. I have no problem with adding the attributes but 
>> see no reason to require their use.
>>
>> Waiting on a good reason for requiring end/start attributes (willing 
>> to add but why require)?
>>
>> Patrick
>>
>>
>>
>>>
>>>
>>> We do not have an attribute to indicate "PresentationType" in any other
>>> element and it could be determined to be useful there as well.  I think
>>> we should remove milestonePT and force people to use type and 
>>> subtype to
>>> describe the type of data the element is and figure out the
>>> "Presentation Type" their style sheet based on the data type. I 
>>> still don't know what milestoneSE is for.  Until this morning I
>>> thought it was for matching up the "S"tart and "E"nd of a pair of
>>> milestones.  If no one can explain what it is for we should remove it.
>>>
>>> Todd
>>>
>>>> -----Original Message-----
>>>> From: owner-osis-core@bibletechnologieswg.org [mailto:owner-osis-
>>>> core@bibletechnologieswg.org] On Behalf Of Patrick Durusau
>>>> Sent: Friday, November 15, 2002 12:42 PM
>>>> To: osis-core@bibletechnologieswg.org
>>>> Subject: Re: Add new quote specific milestone attributes - RE:
>>>>
>>> [osis-core]
>>>
>>>> milestone name inconsistencies
>>>>
>>>> Todd,
>>>>
>>>> Todd Tillinghast wrote:
>>>>
>>>>> Patrick,
>>>>>
>>>>> <snip>
>>>>>
>>>>>>> Todd
>>>>>>>
>>>>>>> Does <qEnd> need globalAttributes?
>>>>>>>
>>>>>> Yes, linked by osisID and splitID values according to the
>>>>>>
>>>>> documentation.
>>>>>
>>>>> I don't see any purpose for splitID for a milestone since a milestone
>>>>> can not be segmented.
>>>>>
>>>>> Are you proposing that we "link" <qEnd> with <qStart> with osisID or
>>>>>
>>> are
>>>
>>>>> you refereeing to some other meaning of "link"?
>>>>>
>>>> Linking with osisID. Present due to globalAttributes.
>>>>
>>>>
>>>>>>> Is there a reason that milestoneSe is required?  What good are
>>>>>>>
>>> start
>>>
>>>>> and
>>>>>
>>>>>>> end milestones without a mechanism to find their partner?
>>>>>>>
>>>>>> I don't read milestoneSe as being required? Reads use="optional"
>>>>>>
>>>>> What I was trying to say and didn't was that I think "milestoneSe"
>>>>> should be required.  (Sorry of the confusion.)  Do you see any that
>>>>> milestoneSe should not be required?
>>>>>
>>>> Sorry, don't see why it should be required. I could simply want to use
>>>> milestoneStart and milestoneEnd without the milestoneSe. (This
>>>> attribute, like milestonePt, was added at Bob's request for pointing
>>>> purposes.)
>>>>
>>>> Patrick
>>>>
>>>>
>>>>> <snip>
>>>>>
>>>>> Todd
>>>>>
>>>> -- 
>>>> Patrick Durusau
>>>> Director of Research and Development
>>>> Society of Biblical Literature
>>>> pdurusau@emory.edu
>>>>
>>>>
>>>
>>
>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu