[osis-core] milestone_Start/End/SE

Todd Tillinghast osis-core@bibletechnologieswg.org
Wed, 30 Oct 2002 09:51:15 -0700


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