[osis-core] New milestone use of elements
Patrick Durusau
osis-core@bibletechnologieswg.org
Wed, 28 May 2003 15:06:04 -0400
Troy,
Troy A. Griffitts wrote:
> Patrick,
> I think Todd would argue that with mB and mE you know if you have
> the end or the beginning milestone.
Yes, but he has yet to answer how the example I gave below is any
different? If there is no matching milestone, you lose the container
semantics. Doesn't matter which way it fails.
>
> And I was arguing early (against both of you, I guess), that if we
> say that the rule is:
Could not have been arguing with me as I was agreeing with you. No,
wait, Troy is capable of that! ;-) (humor)
>
> OSIS milestone semantics are exactly identical to their container
> counterparts.
OK, but I would say that OSIS milestones (such as the elements that we
were going to have in the milestoneSE type attribute) carry the same
attributes at their container counterparts (one reason for this
solution) and can be treated as containers, if the application so
desires. Can also be treated as traditional milestones.
>
>
> Then it seems it would be an INVALID OSIS excerpt that only
> included a start or an end milestone. Patrick, I do realize that it
> would be XML-valid, but NOT OSIS valid, if indeed the above mentioned
> rule was in effect.
We have not covered OSIS fragments, which is what this issues addresses,
which is separate from the issue of the milestone behavior triggering
that you argued for, successfully I might add, in Dallas.
>
> So I guess, in conclusion....
>
> IF ((this indeed is a rule) AND (we concede that the excerpt would be
> invalid)) THEN
> I am in favour of 'mID' instead of any combination of 'mB', 'mE',
> 'mS'.
I am in favor of mID as well. Does it matter that we differ on why? ;-)
Patrick
>
> -Troy.
>
>
>
> Patrick Durusau wrote:
>
>> Todd,
>>
>> Todd Tillinghast wrote:
>>
>>> Patrick and Troy,
>>>
>>> If you require that all milestones be purely balanced then it may be
>>> nearly impossible to deliver a portion of a document, because there can
>>> be an endless series of overlapping milestones. If you artificially
>>> move the milestone marker in order to include it, the milestone will be
>>> misplaced.
>>
>> Whow, whow!
>>
>> No one is "requiring" that all milestones be perfectly balanced. Just
>> observing that if you use <q> as an empty element and get a portion
>> that has only one (I am assuming two were used to simulate a
>> container) such element, that it will not make a meaningful
>> container. It is still a single empty element and you will have to
>> either treat it or ignore it. Did not mean anything beyond that
>> observation.
>>
>>> I think the best solution is to keep the mE and mS attributes AND that
>>> the meaning of an unbalanced milestone be that the document was
>>> truncated.
>>>
>>>
>> Still not answering the question "what is different about"
>>
>> <v>and that is all that he said.<q mID="555"> Quickly I reached for
>> another beer,</v>
>>
>> versus:
>>
>> <v>and that is all that he said.<q mE="555"> Quickly I reached for
>> another beer,</v>
>>
>> ????
>>
>> Note that the assertion is being made by the attribute name and not
>> the attribute value.
>>
>> Just adds another name for the encoder to learn with no payoff.
>> Either way I have an empty element with no matching mID. What more
>> need I know to realize I have only a part of the document?
>>
>>>
>>> About <table> is it possible to not allow it to be broken at
>>> present. Does the fact that <table> requires children and <list> and
>>> <lg> don't,
>>> point to the fact that <list> should require at least one <item> and
>>> <lg> require at least one <lg> or <l> child? Of course this does not
>>> help our milestone strategy. If we do require children for <lg> and
>>> <list> we could exclude <table>, <list>, and <lg> from being broken. I
>>> can go either way.
>>>
>>>
>> Sorry, I think you are missing the point of my post. I was saying
>> that only elements that have no required children elements can take
>> on the empty element form, thus:
>>
>> <q mID="545" /> blah, blah, <q mID="545" /> is possible only because
>> <q> has no required element content. In other words, if the content
>> model of <q> required that it be followed by <p>, for example, you
>> could not validly use the empty element form since it by definition
>> does not have any place for children to occur. Sorry, just a syntax
>> rat hole that I noticed and should have passed over in silence.
>>
>> What I did was to add the mID attribute to all the elements that can
>> be listed in the milestoneSE type attribute.
>>
>> 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 8:32 AM
>>>> To: osis-core@bibletechnologieswg.org
>>>> Subject: [osis-core] New milestone use of elements
>>>>
>>>> Greetings!
>>>>
>>>> Working on the new milestone attribute for all main body elements (as
>>>> suggested by Troy).
>>>>
>>>> Content models for everything looks good, all xs:choice is mixed and
>>>> allows occurs=0 so we should not have any content model problems by
>>>> using the elements as empty elements. EXCEPT, for table and row. Table
>>>> requires <head> and <row> in that sequence, and row requires <cell>.
>>>> Don't see any elegant way around that.
>>>>
>>>> Note that <div> can contain table so that should not be too much of a
>>>> problem. Note that <osisText> contains <header> and <div> so you are
>>>> going to wind up with at least one <div> element as a container.
>>>>
>>>> Does anyone see a problem with the foregoing analysis?
>>>>
>>>> Hope everyone is having a great day!
>>>>
>>>> Patrick
>>>>
>>>> --
>>>> 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
>
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Co-Editor, ISO 13250, Topic Maps -- Reference Model