[osis-core] mID vs mS and mE

[Patrick Durusau]

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