On Aug 30, 2005, at 11:31 AM, Jim Fulton wrote:
Gary Poster wrote:
On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:
Gary Poster wrote:
4 Recognize and document that the 'default' field argument is
actually 'initial value'.
I'm uncomfortable with this.
Initial value is a concept in XMLSchema (http://www.w3.org/TR/
xmlschema-1/#key-iv). The qoute is in W3C-speak, but I'm pretty
sure they are talking about what we are talking about. I think
it does belong in a statement about a logical schema.
I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)
Here's what we say about default in the schema package's README.txt:
"Default field values are assigned to objects when they are
This is a statement either:
- about the past history of an object, or
- about some tool used to create an object.
I don't really see that this is of value in a schema. A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past. There's no way to
evaluate, for example, whether an object satisfies this aspect of
Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms. We then create the object with whatever data
we get from an add form. IOW, we don't really use it is an initial
value to create the object.
I suggest that the default should become a field in a formlib form-
definition, and should be deprecated from schema field.
Hm. I'm not the one to quote computer science definitions, but I
don't think the concept of schema is constrained to 'constraints'. A
schema is a data model. The initial value of a given instance of the
model, whether it be used for object creation or any other kind of
model instantiation (e.g., collecting the data for a search form) is
not unreasonably part of a data model. I agree it is not a
constraint, but I'm not sure that's pertinent.
That said, as we discussed verbally yesterday, a "purity" perspective
suggests we are moving towards a more explicit three-layer cake for
schema fields: interface, relationship, and form field. If that
perspective wins out, then yes, I agree that it fits better on the
Zope3-dev mailing list