[Dev] Re: ad-hoc attributes and schema evolution
Brian Douglas Skinner
skinner at osafoundation.org
Fri Oct 3 12:26:06 PDT 2003
That's an interesting scenario. I had only been thinking of ad hoc
attributes as an end user feature, and I hadn't ever thought about the
issues that might come up if programmers were writing code that relied
on specific ad hoc attributes.
But in my mental model, I think that issue could be fairly easily
resolved just by using namespaces for the ad hoc attributes. That would
work, provided that the programmer explicitly bound the code to the
data, which is something I'd like to see anyway. I think Katie has also
talked about having the code explicitly state what it depends on in the
data model. That definitely isn't in the spirit of transparent object
persistence, but I think transparent object persistence is the wrong
approach for Chandler data access, and even if data access isn't
entirely transparent, we could still strive to have a lightweight
binding that would allow people to prototype easily without creating
explicit schema files.
Right now I think we all still have different mental models for how this
stuff should work, especially with regard to namespaces and for how ad
hoc attributes. What's the best way to resolve that? A written
proposal from one or two people, or more meetings, or incremental
iteration in the code?
John Anderson wrote:
> I've been thinking more about ad-hock attributes. I wouldn't be
> surprised if long-term we will end up needing a way to specify on a
> kind, item or collection basis, that all attributes match always the
> schema. Consider this situation: suppose we come out with our 1.0
> schema. Imagine if parcel writers add their own arbitrary attributes.
> Then later at 2.0 we upgrade our schema to include new or different
> attributes, and we end up using the same name as an ad hoc one used by a
> programmer of a new parcel.
> We could help minimize this problem by requiring that ad hoc attributes
> added to the Chandler schema always be added to a special collection
> contained in the item just for that purpose, and enforce that no other
> ad hoc attributes can be added two Chandler Schema without changing the
> version of the schema.
> On the other hand, items like my model data, which don't have schema and
> can be deleted and re-created when incompatible changes are introduced
> don't require schema enforcement.
More information about the Dev