[osis-core] milestone_Start/End/SE

[Patrick Durusau]

Troy,

Troy A. Griffitts wrote:

>>> Could we do something about these inconsistently long and 
>>> underscored element names and attributes with regard to the 
>>> milestone elements.
>>
>>
>>
>> Such as?
>
>
> ha!  milestone_Start milestone_End Milestone_SE milestone_SE
>
> just about everything that deals with milestones.  The case in 
> inconsistent (even between attributes that (I think) are the same, 
> e.g. milestone_SE and Milestone_SE.
>
> And what happened to our camelCase standard?  Why are we introducing _ 
> for these names?

Looks like editorial typos to me. I am sure I just missed them.

So milestoneStart, milestoneEnd wherever appropriate? (bug release? 
Guess we need to ask Harry if he has made extensive use of them as well.)

Other than the typos, what did you think about the more substantive 
suggestions below?

Patrick


>
>
>>
>>>
>>> Also, I really don't like doing milestones this way.  I lose all my 
>>> attributes and have to *hack* them into subType.
>>>
>>> I really think we need to allow _attribute declared_ milestones 
>>> (same old song I've been singing for 6 months now) with attributes 
>>> mStart and mEnd.
>>>
>>> 2 major benefits:
>>>
>>> Get all of a tag's attributes.
>>>
>>> Tags still get processed in the right place because they really are 
>>> <q> or whatever.
>>>
>>>
>>> I've not heard any voiced detriments in a while and I can't remember 
>>> any that are specifically aimed at why the hideous:
>>>
>>>
>>> <milestone_Start Milestone_SE="yoyo" type="q" 
>>> subType="speaker:Joe|type:blockquote" />
>>> Hi, I'm Joe.
>>> <milestone_End milestone_SE="yoyo" />
>>>
>>>
>>> is better than the elegant and understandable:
>>>
>>>
>>> <q type="blockquote" speaker="Joe" mStart="yoyo" />
>>> Hi, I'm Joe.
>>> <q mEnd="yoyo />
>>>
>> While yours is certainly prettier, ;-), I am not sure it does not 
>> cause more problems than it solves.
>>
>> This is off the cuff but here goes:
>>
>> The issue is when can an element be a milestone and when can it be a 
>> container? If it has required content (only a few of our elements do) 
>> then it cannot ever be a milestone, unless, its parent element can 
>> contain all the things you want to place between the milestones as if 
>> it were a container. Perhaps an example would help:
>>
>> Content model: <div> can contain <p>, <list>, PCDATA, but not <q> and 
>> we allow <p> to be written as a milestone.
>>
>> Content model: <p> can contain <list> and <q>
>>
>> <div><p type="hereP" />some text <list>with list items</list><p 
>> type="hereEndsP"/></div>
>>
>> works.
>>
>> but,
>>
>> <div><p type="hereP"/>some text <list>with list items</list><q>Gotta 
>> ya!</q><p type="hereEndsP"/></div>
>>
>> does NOT, because <div> cannot contain <q>
>>
>> In other words, the content model of the parent would have to match 
>> the content model for the child, plus allowing the child as a milestone.
>>
>> Note that:
>>
>> <div><p>some text <list>with list items</list><q>Gotta ya!</q></p></div>
>>
>> does work, because the <q> is now properly a child of <p> (all the 
>> processor of <div> sees is the <p> and that is properly a child of 
>> <div>. The proper child elements of <p> is specified separately for <p>.
>>
>> I am not necessarily defending the syntax of milestones and if we can 
>> agree on a better one, let's fix it before we release a lot of texts 
>> using it. I don't think the solution is to allow arbitrary elements 
>> to become milestones, particularly since the average user will not be 
>> competent to judge when a content model problem is likely to occur.
>>
>> Patrick
>>
>>
>>
>>
>>>
>>>  :)
>>>
>>> I can't see any good reason to keep things the way they are and I 
>>> guess I'm asking officially that it be changed.
>>>
>>>     -Troy.
>>
>>
>>
>>
>

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