[osis-core] Element Review: <div>
Patrick Durusau
osis-core@bibletechnologieswg.org
Wed, 19 Jun 2002 09:36:20 -0400
Harry,
Harry Plantinga wrote:
>Patrick,
>
>You are right. I didn't see the div option in the choice
>element. I would remove it. What I am trying to accomplish
>is to have a model like this:
>
><div>
> [title, head, paragraph-like stuff]
> [zero or more divs]
></div>
>
>This gives us what a computer scientist would call tail
>recursion, which is easier to handle.
>
Another attempt to see if I understand the model! ;-)
<div type="chapter">
<title>My First Chapter</title>
<p>some content</p>
<div>
<title>Section 1</title>
<p>some more content</p>
</div>
</div>
would be permitted, but:
<div type="chapter">
<title>My First Chapter</title>
<p>some content</p>
<div>
<title>Section 1</title>
<p>some more content</p>
</div>
<p>back to first div</p>
</div>
would not?
Assuming this is a correct representation of the proposed model (please
correct if not!), I am not sure that it is an adequate model for
encoding a wide range of texts. If we were authoring the texts, sure,
that model would work but I am not certain that we don't have texts that
exhibit the behavior seen in the second example.
Also not certain that tail recusion has carried the day in terms of
processing XML files. See
www.xmlpitstop.com/XMLJournal/Article6-November2001/ November2001.pdf
for a brief discussion of tail recursion. Beyond that, it is also not
clear that usefulness of particular parsing techniques should drive our
markup practices, although from an implementers standpoint (and as a
user) that is something that should be kept in mind.
Comments?
Patrick
>
>-Harry
>
>-----Original Message-----
>From: owner-osis-core@bibletechnologieswg.org
>[mailto:owner-osis-core@bibletechnologieswg.org]On Behalf Of Patrick
>Durusau
>Sent: Tuesday, June 18, 2002 4:50 PM
>To: osis-core@bibletechnologieswg.org
>Subject: Re: [osis-core] Element Review: <div>
>
>
>Harry,
>
>Thanks for the note because that was not what I understood you to be
>suggesting.
>
>Harry Plantinga wrote:
>
>>Just to make sure the proposal is clear, what I am proposing is
>>to change the schema from
>>
>><xs:element name="div">
>><xs:complexType mixed="true">
>> <xs:sequence>
>> <xs:element ref="div" minOccurs="0" maxOccurs="unbounded/>
>> <xs:choice minOccurs="0" maxOccurs="unbounded"> [lots of stuff here]
>></xs:choice>
>> </xs:sequence>
>>
>>to
>>
>><xs:element name="div">
>><xs:complexType mixed="true">
>> <xs:sequence>
>> <xs:choice minOccurs="0" maxOccurs="unbounded"> [lots of stuff here]
>></xs:choice>
>> <xs:element ref="div" minOccurs="0" maxOccurs="unbounded/>
>> </xs:sequence>
>>
>Not sure how the suggested solution differs from:
>
><xs:element name="div">
> <xs:complexType mixed="true">
> <xs:choice minOccurs="0" maxOccurs="unbounded">
> Lots of stuff but certainly:
> <xs:element ref="div"/>
> </xs:choice>
></xs:element>
>
>If you are going to have div as an optional element inside of the first
>choice, I am not sure what we are gaining from the second optional div?
>Or am I missing something real obvious?
>
>I am assuming that we allow divs to be siblings in the osisText
>container. (or was a sibling relationship the intent of your second
>optional div?)
>
>osisText then becomes
>
><xs:choice>
><xs:element ref="header" minOccurs="0"/>
><xs:element ref="div" minOccurs="1" maxOccurs="unbounded"/>
></xs:choice>
>
>Patrick
>
>
>>
>>-----Original Message-----
>>From: owner-osis-core@bibletechnologieswg.org
>>[mailto:owner-osis-core@bibletechnologieswg.org]On Behalf Of Patrick
>>Durusau
>>Sent: Tuesday, June 18, 2002 3:46 PM
>>To: osis-core@bibletechnologieswg.org
>>Subject: Re: [osis-core] Element Review: <div>
>>
>>
>>Chris, Harry, Guys,
>>
>>So, instead of forcing:
>>
>><div>
>><div>
>>
>>The voiced preference is for:
>>
>><div>
>>stuff (to use the technical term) ;-)
>><div>
>>
>>?
>>
>>Looks like a problem between keyboard and chair to me. ;-)
>>
>>Unless someone submits killer analysis between now and tomorrow morning,
>>consider it done! Look for it in osisCore_1test13.xsd.
>>
>>BTW,
>>
>>Comments on Harry's echoing of Todd's proposal to collapse
>>front/body/back (they all have the same content models) into div and
>>direct people to use the type attribute?
>>
>>I must confess a vague unease with the proposal but I have no principled
>>argument to make against it. I suspect my reluctance is due to long
>>association with more complex encodings where that distinction makes a
>>difference in content models. Since ours does not, hard to see a reason
>>to not collapse into div other than as syntactic sugar. Not a
>>particularly compelling reason, even to me.
>>
>>Show of hands? (Sans any stones please!)
>>
>>Patrick
>>
>>Harry Plantinga wrote:
>>
>>>I would like to second this comment -- I think the content
>>>model should be changed to have the other stuff, followed
>>>by optional nested <div>s. I consider this to be an
>>>important change.
>>>
>>>The proposed content model, with the nested <div>s as the last
>>>elements in a <div>, is very commonly used in real texts,
>>>as in Chris's example below. On the other hand, I can't think
>>>of any situations where you'd really need to have a nested
>>>div followed by some <p>s, a <divineName>, a <title>, etc.
>>>
>>>Second, (and here's my ulterior motive,) if any nested <div>s
>>>have to be last in a <div>, the content model is easier to
>>>parse. You can parse it with start indicators only, no end
>>>indicators needed. If end indicators are omitted, and you are
>>>using the current content model, parsing problems arise in a
>>>situation like this:
>>>
>>><div divTitle="Chapter 1">
>>><div divTitle="Section 1">
>>> <p> some stuff here</p>
>>> <p>I want this paragraph to be in Chapter 1 but not
>>> in Section 1. How do I do it? I can't!
>>>
>>>Why do we care about omit-endtag in XML, you ask? I'm glad you
>>>asked. We care because we are hoping to edit these documents with
>>>a non-XML application such as OpenOffice Writer. With the proposed
>>><div> content model, you can use the built-in Table of Contents
>>>facility -- or paragraphs of style "div" -- to identify the
>>>start of each div. With the current content model, you'd also
>>>have to insert indicators for the the end of each div, which would
>>>be less intuitive and more difficult.
>>>
>>>-Harry
>>>
>>>
>>>-----Original Message-----
>>>From: owner-osis-core@bibletechnologieswg.org
>>>[mailto:owner-osis-core@bibletechnologieswg.org]On Behalf Of Chris
>>>Little
>>>Sent: Monday, June 17, 2002 2:15 AM
>>>To: osis-core@bibletechnologieswg.org
>>>Subject: Re: [osis-core] Element Review: <div>
>>>
>>>
>>>I'm frequently finding text portions that would best be marked as:
>>>
>>><div>
>>> <title>Some title</title>
>>> <div>
>>> <title>sub-section 1 title</title>
>>> some CDATA
>>> </div>
>>> <div>
>>> <title>sub-section 2 title</title>
>>> some CDATA
>>> </div>
>>></div>
>>>
>>>However, because all divs must precede any other element in a div, this
>>>is illegal. I don't understand why this is the case and it seems like
>>>div should just be added to the choice in div, and the sequence be
>>>
>removed.
>
>>>--Chris
>>>
>>>
>>>Patrick Durusau wrote:
>>>
>>>><div> has: <blockQuote>, <div>, <figure>, <lineGroup>, <list>,
>>>><milestone>, <p>, <q>, <seg>, <speech>, <title>, <verse>.
>>>>
>>>>Question: So we don't have phrase level markup in a <div>? That is how I
>>>>see the content model for <div>, with things like <abbr>, <speaker> and
>>>><w> (to take only three examples) as always occurring in larger elements.
>>>>
>>>>Patrick
>>>>
>>--
>>Patrick Durusau
>>Director of Research and Development
>>Society of Biblical Literature
>>pdurusau@emory.edu
>>
>>
>
>--
>Patrick Durusau
>Director of Research and Development
>Society of Biblical Literature
>pdurusau@emory.edu
>
>
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu