[Dev] Re: ad-hoc attributes and schema evolution

[Brian Douglas Skinner]

Hi John,

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?

- Brian





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.
> 
> John