[osis-core] mID vs mS and mE
Troy A. Griffitts
osis-core@bibletechnologieswg.org
Wed, 28 May 2003 15:41:16 -0700
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
>>
>>
>>
>