[osis-core] New milestone use of elements

[Troy A. Griffitts]

Patrick,
	I think Todd would argue that with mB and mE you know if you have the 
end or the beginning milestone.

	And I was arguing early (against both of you, I guess), that if we say 
that the rule is:

	OSIS milestone semantics are exactly identical to their container 
counterparts.

	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.

	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'.

	-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
>>
>>  
>>
>