Re: [Hibernate-devel] subcollection v collection

[Gavin_King/Cirrus%<CI...@ci...>]

> <!ELEMENT composite-element ( (property|many-to-one|collection|composite-
> element)* )>
>  <!ATTLIST composite-element class CDATA #REQUIRED>

> should be

> <!ELEMENT composite-element
( (property|many-to-one|subcollection|composite-
> element)* )>
> <!ATTLIST composite-element class CDATA #REQUIRED>

Oooh you had me scratching my head, thinking you were right for a second
there. But I think a made a different mistake in the DTD.

> Subcollections are not mentioned in the tutorial;

woops that needs fixing. damn looks like I was way too quick off the mark
with yesterdays file release :( Taking "release early, release often" to
heart....

> I am assuming that
> the difference between a collection and a subcollection is that a
> collection has a name (which is the name of its property of the
> containing class) whereas a subcollection is self-identified as it is
> part of a collection.

Yes - the difference *is* the name attribute. In which case a
collection held inside a composite-element is a <collection>, not
a <subcollection>. The name attribute refers to a property of the
composite element.

> This is similar to the difference between a
> component and a composite-element.

In fact, there is a bigger difference between <component> and
<composite-element>. A <component> may define a collection nested
beneath it using <set>, <map>, <list>, <array>, <primitive-array>.
<composite-element> may NOT. (The obvious semantics of this
would be pathological.) We must constrain collections and (nested)
composite elements to contain only other composite elements and what
Doug earlier called "top-level" collections. I like this name much
better than the nomenclature used in the tutorial.

Now, what _is_ broken in the DTD as it stands (and has been broken
since version 0.9.2) is <composite-elements> inside <composite-elements>.
There is no name attribute, so we can't specify what property of the
nesting class refers to the nested class.

We could fix it quickly, by adding an optional name attribute to
<composite-element> but then that would be very inconsistent with
how collection/subcollection clearly distinguish exactly *when*
you need the name attribute. And I think, as often as possible,
an IMPLIED attribute should indicate an attribute that is *always*
optional, not a case where the user has to figure out for themselves
whether the context requires it.

An alternative fix is to add something like a <subcomposite-element>
tag .... but if I was a user I would be like "subcomposite-element????!!"
"what the hell is that?!" hmmmmmm....can't think of anything better
right now. Is there a better _name_ for it at least? Anyone?

How about adding:

<nested-composite-element name="foo" class="foo.Foo"/>

and renaming subcollection to:

<nested-collection role="bar"/>

Well, at least we've discovered a case for which the semantics are clear
but no test exists. Also I've been meaning to comment that dtd but just
hadn't
had a chance yet. I'll move _that_ to the top of the list....