[osis-core] annotateWork and annotateType

[Steve DeRose]

At 11:29 AM -0600 08/22/02, Todd Tillinghast wrote:
>It is no uncommon for child elements to further describe their parent.

That doesn't seem common to me in XML, though I have few enough 
neurons left right now that I could be blanking on something really 
obvious. Generally don't *attributes* describe aspects of their 
element as a whole, while sub-elements literally constitute *parts* 
of their parent? Like, the redness of a car would an attribute, while 
a wheel would be a part.


>
>
>Any time there can be more than one of a data type that describes an
>element child elements are employed when the data is not a single token
>which precludes the use of a list attribute.

That seems incorrect to me too; it does happen, but there are 
certainly other cases -- that, for example, is why there is an IDREFS 
attribute type, and why there have been many proposals that 
attributes should allow internal structure (as in the new Layered 
Markup and Annotation Language (LMNL), or as in my failed proposal in 
the XML WG to make attributes be LISP s-expressions).

>I this case type/role/purpose of the describing data can not be
>enumerated at schema design which indicates the use of a child element.

That seems a third and different criterion, but I also don't see that 
one as being why people put things in sub-elements.

>
>In this case the set of possible types of reference decorations for an
>element is a large set (annotation being only one case).  We could add a
>pair of attributes (one for the reference and one for the type) for each
>case.  This would leave us with an element with a large number of
>attributes and would be tailored to the purpose of the people with
>enough influence to get the attributes added for the purposes that are
>important to them.  Since XML does not allow us have more than one
>instance of each attribute name we can not simply add osisRef, refType,
>and refSubType to the parent element.  The alternative being used is a
>child <reference> element that serves the same purpose.

Ok, here I think I see you're getting at wanting a repeatable tuple 
-- yes, for that XML attributes don't work. But why do we need the 
triple of osisRef/refType/refSubType repeatable on an element?

>
>When I got moved to CO and was back keeping up with postings, I saw that
>annotation related attributes had been added and understood that they
>could not use the <reference> mechanism because they referred to an
>entire work, which was a problem for <reference>s at that point, so I
>did not object to the addition of these attributes at that point.
>However, since the behavior can be accommodated with the <reference>
>mechanism there is no reason to retain attributes.

I see your point re. no need for duplication of attrs and content. I 
seem to remember we had a special semantic in mind for the ref attrs, 
which presumably was not repeatable. But I think my last neuron just 
gave up, so I'm going to go get supper and check in later. If there's 
no such special+unique semantic to such a reference attr, I'd be 
happy to lose it since, as you point out, we've already got 
references down in content we can use.

>
>There is little difference between
>//*[@annotationWork="Matt.1.13"][@annotationType="commentary"] and
>//*[child::reference[@type="annotation"][@osisRef="Matt.1.13"][@subType=
>"commentary"]]
>
>This also allows for a you to have a commentary on multiple texts.  A
>case I can see is if the commentary is on a set of parallel texts from
>the four gospels.  You could say:
><p>
>	<reference type="annotation" osisRef="Matt.x.y"
>subType="commentary"/>
>	<reference type="annotation" osisRef="Mark.a.b"
>subType="commentary"/>
>	<reference type="annotation" osisRef="Luke.c.e"
>subType="commentary"/>
>	<reference type="annotation" osisRef="John.s.t"
>subType="commentary"/>
>	<reference type="topic" osisRef="naves:GRACE"/>
>...commentary...
></p>
>
>
>By using this strategy we can support multiple "adornments" of a variety
>of types and have not added attributes that serve only special cases.
>
>Todd


-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sjd@stg.brown.edu