On Sun, 05 Sep 2004 19:51:44 +0200, Pierre-Frédéric Caillaud
<lists@boutiquenumerique.com> wrote:
>> But after looking closely at the list of a possible properties, i found>> out that some of them depend on others.
Forexample, if item is a>> PDF document, it can have an index. But a document can also have an>> index with links.
Logically,a properties like 'index with links'>> don't belong to the verification table - they look like a kind of>> a
compositefield - 'index with links' is not a stand-alone property,>> but it also implies that an item also has an
'index'property.>> On the other hand, it is impossible to decouple 'index' from>> 'with links', because the second part
won'thave any meaning without>> the first part.>> You mean your properties would be better organized as a tree ?>
Oris it even more complicated than that ?
I never thought about that possibility - it is an interesting idea,
and it solves the logical problem (though there is still a need to
ensure that if child property is set, that the user won't be able
to also set a parent property - which is probably implementable by
using triggers).
Though I would prefer, if it is possible, something much simpler,
because there are only about 10 properties and 2 'composite'
properties - it would probably be an overkill to create a tree for
such a small table if a simpler solution exists.
Daniel.
