[osis-core] mID vs mS and mE
Patrick Durusau
osis-core@bibletechnologieswg.org
Wed, 28 May 2003 19:24:07 -0400
Todd,
Todd Tillinghast wrote:
>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.)
>
>
Actually the software that a user has chosen could add it as well.
Recall that before the file can be used it must be processed. If you
want the added features that mType provides, add it when you build the
in memory representation of the document. As Troy points out, if you
have the entire document, you can add them automatically. Probably the
best way to author as well, just stick in the mID and then run a script
to insert the mType values. Would be vastly more accurate and less time
consuming than having users do it by hand.
>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).
>
>
Actually we only have to tell them to use the same mID for both ends. As
noted above, the rest should be a processing issue, on Windows and Linux
anyway, don't know about Macs.
Note: most of tomorrow will be lost due to taking Carol's car to the
shop, Carol to work, Elizabeth to the airport, Carol to pick up a car
and then my driving to Athens, GA for a conference. I will probably be
back online tomorrow night. Have most of the stuff in the schema, but
not nearly all. Will try to finish by Saturday if at all possible with
an alpha version, beta to appear middle of next week.
Hope everyone is having a great day!
Patrick
>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
>>
>>
>
>_______________________________________________
>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