[osis-core] milestone_Start/End/SE

[Troy A. Griffitts]

How would this solve my problem?

I want to make a stylesheet that can take advantage of things like: <q> 
and <p> probably not needing any different processing between the 
container opposed to the milestone versions.

I think the only possible benefit is that it allows you to know the 
difference between milestones and non milestones by the name, and not 
the attribute.  But I think this is just as much a detriment for other 
reasons.

The obvious detriment is what you suggested below, we x2 our elements.





Todd Tillinghast wrote:
> I'm not sure I would want to do this but it is possible to derive by
> extension new elements that have no children and are empty elements but
> retain the attributes.  An "m" could be added such that <mp> is the
> milestone derivation of <p> and <mlist> is the milestone derivation of
> <list> etc...
> 
> This seems to solve the issue Troy is after with the attributes and the
> issue Patrick has.  Trouble is that there would be a large number of new
> elements.
> 
> Question would be do we have <mpStart> and <mpEnd> and add in the start
> and end attribute identifiers as well?
> 
> Todd
> 
> 
>>-----Original Message-----
>>From: owner-osis-core@bibletechnologieswg.org [mailto:owner-osis-
>>core@bibletechnologieswg.org] On Behalf Of Patrick Durusau
>>Sent: Wednesday, October 30, 2002 6:31 AM
>>To: osis-core@bibletechnologieswg.org
>>Subject: Re: [osis-core] milestone_Start/End/SE
>>
>>Troy,
>>
>>Troy A. Griffitts wrote:
>>
>>
>>>The case of milestone_SE is defined differently in Start and End
>>>
>>>
>>>Could we do something about these inconsistently long and
>>
> underscored
> 
>>>element names and attributes with regard to the milestone elements.
>>
>>Such as?
>>
>>
>>>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
>>
>>
> 
>