[Zope3-dev] Interfaces and Schemas

[Martijn Faassen]

Steve Waterbury wrote:
> This actually goes to the root of the issue: the
> types of applications for which Zope and Zope 3
> are designed is browser-centric, so interfaces and
> schemas are generally simple and can be handled
> identically.  This is not the case for my application,
> which will interact with browsers, "thick" gui
> clients, and complex applications such as CAD/CAE
> tools and Product Data Management systems, for which
> the distinction between schemas and interfaces
> is quite pronounced.

Why is this so? I don't see why a different clients will make
things different. After all Zope separates views from content.
For the web view of schemas there is the 'form' package, but nothing
stops anyone from creating another package for some other GUI app.
Note that the form package treats an interface as a schema,
in the sense that method information is ignored.

Or are you suggesting that creating/editing fields is different than
manipulating methods? In this sense there is a difference; though you
can present a GUI for manipulating methods on an interface, you'd not
be done then -- you'd need to implement the methods. Fields are more
complete in this sense, and code (from a GUI for instance) to generate
schemas can make sense in various application domains.

I don't think there is anything from stopping you to do so with Zope 3's
schemas.

> The distinction is only observable at high energies.
> Zope space is more Newtonian.  (Okay, I guess I've
> beat that metaphor to death! ;^)

> >This was our original design, but Jim was hitting with a hammer on my head 
> >insisting that this is not a good idea. :-) I believe him now. The 
> >separation between interface and schema objects would be artificial and 
> >would introduce a lot of unnecessary complexity. 
> 
> I suspect that this is true within the design context
> of Zope 3.
> 
> >BTW, you contradict yourself here; first you tell me that schemas and 
> >interfaces should be equal, but then you write about a separation of the 
> >two.
> 
> See above -- I meant "equal" in status, although distinct
> in semantics.  Basically, a schema is a "content model"
> (a.k.a., an information model); an interface is an API.
> They are different in the same way that information
> modeling is different from object modeling (e.g.,
> E-R modeling vs. UML modeling), although in first-order
> cases they can have large overlaps or even be identical.

> Another way of looking at it is that interfaces treat
> objects as "black boxes" with specified behaviors,
> whereas schemas treat them as "white boxes" (or at
> least "translucent boxes") for which a well-defined
> set of properties are exposed.

This distinction is similar to the one I drew above. While this is indeed
the case, this does not mean a schema should not be a kind of interface,
nonetheless. :)

> In relatively trivial areas (get and set), API's are
> of course semantically equivalent to schemas.  (The
> first-order case.)
> 
> >We think that this separation is YAGNI! Note that we also usually do not 
> >specify accessor and mutator methods, since we use Python's property 
> >functionality. 
> 
> I can understand that this distinction might be YAGNI
> for Zope, but I don't think it is for my application context.

Nothing stops you from creating a system that just manipulates the
subset of interfaces that is schemas (i.e. interfaces with fields
only). For some initial code that can do something along these lines
see the 'zope.app.schemagen' package.

The separation between interfaces and pure schemas can exist with Zope's
schemas, if you want it to exist. But the conclusion early on was
that it was wrong to restrict the two from overlapping.

> >>Perhaps more importantly, is it of interest at all?
> >
> >Seperating Interfaces and Schemas? Probably not in the near future. We are 
> >really happy about our Interface/Schema functionality.
> 
> Thanks, that answers my question!
> I'll go back and play in my sandbox now.  :^)

As long as you don't create your own schema system because of this thread.
Let's first see about some use cases of 'high energy' environments so
that we can *really* determine whether Zope 3's schemas don't allow
what you are interested in. If so, good for all of us. If not, then we learn 
something too, and perhaps work on improving matters.

Regards,

Martijn