Cr20160114

Version 4 (Nicolas Houillon, 15/01/2016 17:58) → Version 5/6 (Nicolas Houillon, 15/01/2016 17:58)

h1. Objets

h2. Champs supplémentaires

L'ajout de champs n'est possible qu'à travers la création de catégories, pour obliger à documenter leur fonction et/ou leur provenance.

Nécessité d'un garbage collector pour gérer les champs/catégories non utilisés.

h1. Représentation

h2. Modèle de base

* @id@
* @owner@
* @etiquette@
** @type@ (Aldo, ex 100pc, ...)
** @label@
* @date(s)@

@type@ permet d'identifier les représentations pour les traitements de masse
@label@ permet de différencier plusieurs instances d'une représentation d'un type donné

h2. Champs supplémentaires

* @type@ ajoute une liste de champs (ex type MIME, ...)
* @type + label@ ajoute une liste de champs
* champs additionnels possibles à la demande (documentés)
> champs additionnels sous forme de catégories ?

Nécessité d'un garbage collector pour gérer les champs champs/catégories non utilisés.

h1. Concurrence de valeurs de champs

Chaque entité qui manipule un objet doit pouvoir lui ajouter des catégories.
Chaque entité qui manipule un objet doit pouvoir fixer des valeurs à des champs, quelle que soit l'entité qui a ajouté la catégorie auxquels appartiennent les champs.
Les valeurs renseignées par chaque entité n'écrasent pas les données des autres, elles s'y ajoutent, et sont visibles par tous.

Il y a plusieurs manière de définir ce qu'est une entité : process, personne, hiérarchie, autre chose ? Le débat fait rage.

Il devrait y avoir un mécanisme similaire pour les valeurs de champs additionnels sur les représentations.