Re: [Modeling-users] XML model suggestion

[Mario R. <ma...@ru...>]

OK. The suggestion is essentially a cosmetic one, and probably
an even stronger argument against it would be that the changes
it will necessitate are not worth it. My aesthetic sense makes me
prefer less verbose XML... the argument that a pk is really an
attribute of an entity and not of an attribute seems reasonable--if
it would ever be possible that this fact may manifest itself in
some physical way, e.g. would it be ever possible to "share"
attributes between entities (such as inheritance) but that in
an entity a given attribute may be a pk but in another entity
the same entity is not.

In any case, this is low-priority.

Cheers, mario


On jeudi, f=E9v 20, 2003, at 22:57 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:

>
>         Hi,
>
> Mario Ruggier <ma...@ru...> writes:
>> familiarizing myself with the framework, I suggest the following
>> modification to the XML to describe a model:
>>
>>   Instead of the XML elements:
>>
>>        <primaryKey ...
>>        <attributesUsedForLocking ...
>>
>> use XML attributes on the <attribute> XML element, i.e.
>>
>>        <attribute ... primaryKey=3D"1" ...
>>        <attribute ... usedForLocking=3D"1" ...
>>
>> This seems clearer, is less verbose,
>
> Well, the reason why it is like this entirely comes from Entity's API:
> these two elements really point out an entity's (not an attribute's)
> characteristics.
>
>   For attributesUsedForLocking: yes, I guess this could become an
>   attribute of the <attribute> tag (this tag is not used yet but will
>   identify the columns to be checked when optimistic-locking is
>   implemented). But to me this looks more like an entity's property=20
> than
>   an attribute's one.
>
> As far as the primaryKey is concerned, my opinion is much more
> mitigated. The primary key is a very important element in
> Entity-Relationship Modelling: not only because it uniquely identifies
> the row/object, but mainly because without it, no relationship/join =
can
> be defined --you may argue that foreign keys are not identified that
> way, true. Moreover and again, this designates a property of an =
entity,
> not an attribute's one.
>
>> and in any case keeps open your options to support changing your mind
>> about enforcing only one such attribute for each case -- should the
>> framework evolve that way.
>
> In that case, more than one <primaryKey> would be present in an =
Entity.
>
> I understand these are not strong reasons not to make the change, and
> that every of them can be argued: in this case, for example, why aint
> 'isClassProperty' or 'isRequired' element of entity?!
>
>   However I feel somehow reluctant in removing these tags from the
>   entity.  Maybe I'm too used to it, or maybe it partly comes from the
>   fact that I already feel a bit touchy about the xml-file, which=20
> should
>   be more human-readable than it actually is. I'll think about your
>   suggestions, though. And feel free to share if you have more=20
> arguments
>   for it, and to insist about that :)
>
> -- S=E9bastien.
>