[osis-core] mID vs mS and mE

Todd Tillinghast osis-core@bibletechnologieswg.org
Wed, 28 May 2003 16:58:06 -0600 

This is better than the "s---"/"e---" option but if the attribute is
optional then some encoders would only use the mID and not the mIDType
so the attribute would probably not end up being consistently used and
thus not reliable.  (It is true that you can change a document to add
the mIDType, but this option is only available to the author not the
user.)

This also adds two attribute the same as mS and mE.

Are we trying to use mID and not mS/mE because we don't want to have to
explain how a user should use the two attributes?  It seems to me,
either way we will have to tell users that they have to put a start and
end milestone and they all have to match up as pairs based on the m*
value.  It is actually MORE readable to the end user to see mS/mE
because they know which way to look to find the partner.  With mID the
user (the same as the software) does not know which way to look for the
partner (of course the mIDType would solve this, but introduces the
consistency problem).

Todd

> -----Original Message-----
> From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> admin@bibletechnologieswg.org] On Behalf Of Troy A. Griffitts
> Sent: Wednesday, May 28, 2003 4:41 PM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] mID vs mS and mE
> 
> I know all we need is ANOTHER option, but this is also a solution for
> those who want it:
> 
> <xs:simpleType name="mIDType">
>    <xs:restriction base="xs:string">
>      <xs:pattern value="((\p{L}|\p{N}|_)+)((\.(\p{L}|\p{N}|_)+)*)?"/>
>    </xs:restriction>
> </xs:simpleType>
> 
> <xs:simpleType name "mType">
>    <xs:restriction>
>       <xs:enumeration value="s"/>
>       <xs:enumeration value="e"/>
>    </xs:restriction>
> </xs:simpleType>
> 
> <xs:attributeGroup name="milestoneable">
>    <xs:attribute name="mID"   type="mIDType" use="optional"/>
>    <xs:attribute name="mType" type="mType"   use="optional"/>
> </xs:attributeGroup>
> 
> 
> The advantages:
> 
> We can still 'match' on identical mID's with simple logic.
> 
> If anyone WANTS to, they can specify the mType="s" or mType="e".  It
> also lets someone who needs them for their processing to parse the
doc,
> top-to-bottom and add them if they wish.
> 
> It pushed the functionality to an attribute value, like Patrick wants
> (and I agree seems more sensible).
> 
> It still lets you do one check (which we lose with mS|mE): IF (tag
> contains the mID attribute) THEN it is a milestone.
> 
> 
> 
> 
> Patrick Durusau wrote:
> > Todd,
> >
> > Todd Tillinghast wrote:
> >
> >> Troy and Patrick,
> >>
> >> Regardless of how the fragmentation issue is resolved I would like
to
> >> see mS and mE rather than mID because I know which way (forward vs
> >> backwards) to look for the matching milestone AND in many cases I
can
> >> ignore one or the other milestone.
> >> Up with mS and mE and down with mID!
> >>
> >>
> > Thanks for sharing! I would not have spotted that from your earlier
> > posts. ;-)
> >
> > Two comments that I discussed with Steve this morning:
> >
> > 1. Authors have to learn and use two names (correctly) to reach the
> > behavior you want.
> >
> > 2. Note that it is not the attribute value but the attribute itself
that
> > is carrying the information you seek. Not saying that can't happen,
just
> > makes me uneasy since in most situations it is the attribute value
that
> > carries the load. (The may be just generalized uneasiness but I will
> > look in some of my more theoretical markup stuff before I leave
tomorrow
> > for Athens to see if anyone has put a name to this.)
> >
> > Hmmm, what if the attribute name remains mID and is xs:string, and
the
> > basic level encoding is just matching mIDs and say level 2
encodings,
> > have mIDs of "s----" and "e----"? That puts the burden on the value,
> > where my gut says it should be and leaves the inexperienced encoder
with
> > only one name to remember. Matches of mID are s* and e*.
> >
> > Comments?
> >
> > Patrick
> >
> >
> >> Todd
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: osis-core-admin@bibletechnologieswg.org [mailto:osis-core-
> >>> admin@bibletechnologieswg.org] On Behalf Of Patrick Durusau
> >>> Sent: Wednesday, May 28, 2003 1:15 PM
> >>> To: osis-core@bibletechnologieswg.org
> >>> Subject: Re: [osis-core] New milestone use of elements
> >>>
> >>> Troy,
> >>>
> >>> This is the fragment issue. It is tough sledding and if anything,
I
> >>> think we need to address it in August, assuming we can be ready by
> >>>
> >>
> >> then.
> >>
> >>
> >>> Let's mark it as know issue.
> >>>
> >>> For the moment, I would say from an encoding standpoint that when
you
> >>> use the mID, you have to use matching elements with the same value
for
> >>> mID. Ducking the issue of querying b/c of the fragment question.
> >>> Answering that requires a lot more than simply matching the
milestone
> >>> element.
> >>>
> >>> Note that Todd's proposal is not an answer either since getting mS
or
> >>>
> >>
> >> mE
> >>
> >>
> >>> does not answer the question either. I need to know what mS that
an mE
> >>> is pointing towards, not merely that they match, since they could
be
> >>>
> >>
> >> all
> >>
> >>
> >>> over a text. Now we have the encoder using different attribute
names
> >>>
> >>
> >> and
> >>
> >>
> >>> pointing to other values, i.e, not the element they are on. Easier
to
> >>> off load this problem onto the application and not the encoding.
see
> >>>
> >>
> >> for
> >>
> >>
> >>> example: http://www.w3.org/TR/xml-fragment for how the W3C treats
XML
> >>> fragments.
> >>>
> >>> Patrick
> >>>
> >>> Troy A. Griffitts wrote:
> >>>
> >>>
> >>>
> >>>> ok, I know replying to myself is a little wierd, but after
further
> >>>> thinking....
> >>>>
> >>>> I understand the POSSIBILITY that there may be an excerpt with a
> >>>>
> >>>
> >> start
> >>
> >>
> >>>> or end quote.  We probably should allow it.  If someone wanted
the
> >>>> last 10 verses of Jesus' Sermon On The Mount, I'd expect it to
end
> >>>> with a </q>
> >>>>
> >>>> BUT I still don't think we should allow a milestone without it's
> >>>> start/end counterpart.  That's like saying we'd allow </q>
without
> >>>>
> >>>
> >> the
> >>
> >>
> >>>> <q>.
> >>>>
> >>>> I think we need to be hard and fast about the rule I stated
earlier.
> >>>>
> >>>> So, thinking further.....
> >>>>
> >>>>
> >>>> If I wanted to encode an excerpt that started in the middle of a
> >>>>
> >>>
> >> quote
> >>
> >>
> >>>> and contained the end of the quote.....
> >>>>
> >>>> How would I encode it????
> >>>>
> >>>> Let's not even think milestones here.  MILESTONES should not ADD
> >>>> functionality... Like providing the ability to solve this
> >>>>
> >>>
> >> problem....
> >>
> >>
> >>>> Would something like this be valid:
> >>>>
> >>>> <q type="continuation">....</q>
> >>>>
> >>>>
> >>>> dunno the best way to solve it, but it should be solved the same
> >>>> whether using an XML container or a milestone.
> >>>>
> >>>>    -Troy.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> osis-core mailing list
> >>>> osis-core@bibletechnologieswg.org
> >>>> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> >>>>
> >>>>
> >>>
> >>> --
> >>> Patrick Durusau
> >>> Director of Research and Development
> >>> Society of Biblical Literature
> >>> Patrick.Durusau@sbl-site.org
> >>> Co-Editor, ISO 13250, Topic Maps -- Reference Model
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >>
> >>
> >
> 
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core