[Zope3-dev] ZConfig schema extensibility q's

[Phillip J. Eby]

At 03:22 PM 9/23/03 -0400, Fred L. Drake, Jr. wrote:

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

Very cool!  Thanks.


>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.  ;-)

There are no *unit* tests.  Another developer at my shop used it in a 
*functional* test.  :)


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

Hm, good points.  Sounds like "valuetype" should not be inherited at all.

Keytype is a more complex case, though.  Technically, it seems to me that 
you should be able to have a derived schema use a different keytype, as 
long as that keytype accepted any key that the base schema(s) would.  But I 
believe I could live with a requirement that all the *inherited* keytypes 
should be the same.


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

Urgh.  I'm not keen on this.  How about, you don't have to specify it 
unless there is more than one datatype specified by the immediate 
bases?  IOW, specification would be required for disambiguation.

To sum up, here's what I propose:

* valuetype should not be inherited at all

* keytype and datatype must be specified, *unless* all of the listed base 
schemas refer to the same type.  (IOW, if you're doing single inheritance, 
you shouldn't need to specify them.)

The former should be implementable by just deleting some code from my 
patch, and the latter should be doable by adding an "if not OK: raise 
whatever" clause to the end of the start_schema() method.


>  > Multiple URLs can be supplied to the "extends" attribute, separated
>  > by whitespace.
>
>Should the same treatment apply to sectiontypes?

Eh?  I don't understand.


>  > 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?

Hm.  Interesting possibility, but it could take a lot more work to 
implement.  In essence, you might need to *modify* the existing definitions 
of those items in-place, because other types might have references to 
them.  Anyway, I'm not currently being bothered by that limitation.  The 
other items discussed above seem much more valuable in the short term.

Or, to put it another way, until we have some kind of schema extensibility, 
nobody will be able to *have* the problem that you're talking about, yet.  :)