[Zope] zope.schema: association vs. containment in Object, List

[Sean Upton]

On Fri, Jun 6, 2008 at 7:24 AM, Fred Drake <fdrake at gmail.com> wrote:
> Still another approach, if you're looking to create software support
> and the first isn't suitable, is to use fields that provide additional
> interfaces that indicate the nature of the references.

My application (and I suspect other cases will) need to do just this;
a marker on the field eliminates the ambiguity.  Schema and interfaces
should allow for complete "domain modeling" in such a way that
expresses intent of the business case, regardless of the persistence
mechanism or implementation details underneath, so I think I'll
continue to use custom field types marked with an IRelationshipField
interface, and assume the built-in Object, List fields are only used
for containment.  The only thing I do not like about my direction is
that it leaves ambiguity when working with code from other
components/projects that do not share this assumption.

For RDBMS persistence of schema-defined content, z3c.dobbin (for
example) assumes Object fields are just foreign-key relationships, but
the downside to this simplification is an inability to meaningfully
interact with a simple persisted containment scenario (a complex
object that has contained specialized child objects intrinsically part
of the primary object; trying to serialize to JSON with clear
recursion boundaries for example, would be difficult).  In my
application-case, I'm looking to do something similar, but hoping to
do so with a clear bright-line between associations and containment.

Note: removal of such ambiguity is helpful for the possible use case
of schema/interface bootstrapping/generation from UML tools for
model-driven-design.

Sean