[osis-core] mID vs mS and mE

[Todd Tillinghast]

The "s---" and "e---" approach is logically equivalent but would be
messier to handle and would be a "can barely live with" rather than a
"preferred" solution.

I suspect I would end up having to use string manipulation functions to
determine if a mID begins with an "s" or "e" and then removing the
character to determine quality.

"verse[beginsWith(@mID, "s") and substring(@mID, 2,
string-length(@mID))=(same sort of thing for the other matching
milestone)] ... more conditions"

vs

"verse[@mS and @mS=following::verse/@mE]... more conditions"

(There could be syntax errors in the above quickly created examples but
I think they give you the idea.)

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 3:54 PM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] mID vs mS and mE
> 
> 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
> >
> >
> >
> 
> --
> 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