[Zope3-dev] ZConfig schema extensibility q's

[Fred L. Drake, Jr.]

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

So unit tests are certain to either find bugs or be incomplete.  ;-)

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

Sounds right to me.

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

So you'd need to check that

- the "inherited" keytype and the actual keytype return the same thing
  for all keys in the the base schema

- the actual and "inherited" keytypes don't produce conflicts for the
  keys introduced by the derived schema (for each key introduced, the
  inherited keytype either raises an exception or returns something
  different from what it returns for any of the keys it defines)

  (This is a pretty fancy constraint; I'd suggest KISS until you know
  you need this, if only to keep the implementation simple.)

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

Nope; the base datatypes would have to all be the same to "inherit"
it, otherwise something is lost.  But most reasonable apps will just
use the "null" datatype for the schema, so that should not be a big
deal in practice.

An unspecified datatype is equivalent to a specification of "null" for
schema; doing what you describe means that "null" isn't really a
specification for datatype anymore.  This will bite someone in a
mysterious way; better to require explicit control.

 > To sum up, here's what I propose:
 > 
 > * valuetype should not be inherited at all

Agreed.

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

For keytype: agreed.
For datatype: see comments above.

 >>> Multiple URLs can be supplied to the "extends" attribute, separated
 >>> by whitespace.
 >>
 >> Should the same treatment apply to sectiontypes?
 > 
 > Eh?  I don't understand.

Section types can extend another section type; should they support
multiple "bases" as well?

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

No; I think you're thinking about section *types*, not section and key
instances.

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

I've got a description of an %import keyword to allow the equivalent
to <import package='...'/> from the config file syntax, and Shane has
indicated in discussion that it sounds like a good thing.  (It would
be useful with his Ape, and allow Ape to be used without changing
zopeschema.xml; it could also be used for things like
DirectoryStorage.)  I'll post my description of that later (intending
that to mean "later *today*").


  -Fred

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