[Zope3-dev] ZConfig schema extensibility q's

[Fred L. Drake, Jr.]

Phillip J. Eby writes:
 > Why is it not allowed for one ZConfig schema component to extend a 
 > definition supplied by another schema component?  This is explicitly 
 > checked for by ZConfig, but I don't understand why.  It seems to me to be 
 > the same as one Python module subclassing a class that's exported by another.

Probably overdesign on my part.  Given the general gist of the
comments I've seen about ZConfig on the lists and heard in discussions
here, I now think this restriction should be lifted.  I'll make the
change if you don't beat me to it.

This is separate from the schema-extension ideas discussed below, and
need not wait for us to work those issues out.

 > Second, you can't currently extend a top-level schema, but must instead 
 > copy it verbatim into a new schema.  Per previous discussion here, I have 
 > created a patch to support the <schema extends="url url url..."> format:
 > 
 > http://cvs.eby-sarna.com/PEAK/src/ZConfig/schema.py.diff?r1=1.4&r2=1.5
 > 
 > I'd like to find out if there are any objections to me adding it to the 
 > "real" ZConfig, before I work on docs and tests for it.  The change allows 
 > you to define a new schema by extending an existing one, e.g.:

Not sure how you implemented it if there are no tests.  ;-)

 > <schema extends="url-of-existing-schema">
 >      <import package="my.package">
 >      ...etc.
 > </schema>
 > 
 > The "datatype", "keytype", and "valuetype" are determined in "classic MRO" 
 > order.

The keytype should match for all schemas involved.  The valuetype
should be taken from the schema that provides the definition of the
key.

Getting the datatype using the classic MRO algorithm makes me a little
uncomfortable.  I'd be happier to say that if any of the "base" schema
set the datatype, the derived schema would be required to specify the
datatype (which can be "null" to specify the default conversion).

 > Multiple URLs can be supplied to the "extends" attribute, separated 
 > by whitespace.

Should the same treatment apply to sectiontypes?

 > Extending a schema is logically equivalent to including its body in the 
 > extending schema's body, before the content of the extending schema's 
 > body.  This approach has a limitation, however: you can't redefine/override 
 > anything that's defined by the base schema, because that's equivalent to 
 > trying to define it twice in the same schema.

I'm not sure that's a bad limitation though.  ;-) Perhaps there should
be an attribute on the key, multikey, section, and multisection
elements to note that they are expected to override definitions from
the base?


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation