Re: [Modeling-users] Re: Implementing inheritance through vertical mapping

[Sebastien B. <sbi...@us...>]

        Hi Mario,

Mario Ruggier <ma...@ru...> wrote:
> Hi, sorry about the late jump-in, just a few comments:

No problem :)

> I see the XML just as an exchange format for a model, if you need
> to import, generate or export a model definition _programmatically_.
> IMHO, to develop your XML by hand is silly, as it is ugly, way too
> verbose, and very obscure and un-expressive -- it is very difficult
> (for me ;) to visualize a model from its XML definition. So, the XML
> should only be manipulated by tools -- in which case it does not
> matter whether properties are flattened or not.

As far as flattened properties are concerned, implementing them will add
new declaration(s) in either the xml-model or the pymodel, in a
completely backward compatible way.

  And yes, now that we have pymodels, we can say that designing a
  xml-model by hand is unappropriate :)

> However, if one still wants a more human-friendly XML, what's the
> problem with either assigning generic default values for xml element
> attribs (e.g. parentEntity=3D'',  isReadOnly=3D'0', isAbstract=3D'0', etc=
, if
> not present), or  "inferring" the value of specific attribs from the
> parent entity if one is set. Elements are "identified" by they nodename
> and by the value of the name attribute. For example, the famous
> Employee entity can become (leaving out PK, and Rels for simplicity) :
[snipped example]
> The default values are more "limited" than in PyModels, as they apply
> to nodeType[@name]/@attrib, and to nodeType[@name]/* (children).
> It is then a matter of pre-processing to generate from the above the
> same identical full XML for these 2 entities as in the current
> StoreEmp example, thus no runtime code would need to be touched
> in any way. The pre-processing could be done also as an XSL
> transformation or so, or with any old dom manipulation technique.
> Also, no backwards compatibility issues, as if something is specified
> explicitly, then it is not affected by this mechanism.
>=20
> But, I question whether doing all this is worth it... in the end it will
> still always be way more cumbersome than PyModels (also in
> performance!).

I really do not feel like going that way; xml-models are a complete dump
on models in memory at runtime, they are advertized as-is, and I have
the strong feeling that this should remain untouched.

  First, because xml has no declared explicit way of specifying
defaults, except those declared in the classes Model, Entity, etc., but
that's not explicitely supported, nor recommended, nor checked, and
changing the defaults in these classes could possibly slightly change
the semantics of some fields in the xml --while on the other hand the
pymodels have an explicit mechanism for notifying changes between
version, that's the model's attribute 'version'. Second, because
introducing such a feature (lighter xml for inheritance), apart from
representing a real work, will probably not be used at all: as you
noted, even with this, all in all they would remain far more cumbersome
than pymodels.

> Hey, and it can also generate the xml so trivially ;)

  One more reason, I'd say ;)

  May I repeat it again, all this does *not* mean that xml-models are
  about to be deprecated. People are using it in various ways, including
  auto-generating them from other xml-sources. It just means that we
  won't probably change the way it is now: an explicit, comprehensive
  serialization of models used at runtime.


-- S=E9bastien.