Cr20160114
Version 2 (Nicolas Houillon, 15/01/2016 16:51) → Version 3/6 (Nicolas Houillon, 15/01/2016 17:52)
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 detector/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
ndr : @type@ pourrait fonctionner comme les catégories ?
Nécessité d'un garbage detector/collector pour gérer les champs/catégories non utilisés. objet
h1. Concurrence de valeurs de champs Hiérarchies
Chaque entité qui manipule un parent d'un objet doit pouvoir lui peut ajouter des catégories.
Chaque entité qui manipule un objet doit pouvoir champs (en ajoutant des catégories) et les remplir, mais aussi fixer des valeurs à des champs, quelle que soit l'entité qui a ajouté la catégorie auxquels appartiennent les champs. champs existant (remplis préalablement ou pas).
Les valeurs renseignées par chaque entité n'écrasent données à travers un parent n’écrasent pas les valeurs données des autres, par les autres parents, 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 rajoutent.
> Les catégories rajoutées sont-elles ajoutées globalement à l'objet ou localement comme les valeurs de champs additionnels sur les représentations.
?
> Si globalement, a-t-on un suivi des catégories ?
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 detector/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
ndr : @type@ pourrait fonctionner comme les catégories ?
Nécessité d'un garbage detector/collector pour gérer les champs/catégories non utilisés. objet
h1. Concurrence de valeurs de champs Hiérarchies
Chaque entité qui manipule un parent d'un objet doit pouvoir lui peut ajouter des catégories.
Chaque entité qui manipule un objet doit pouvoir champs (en ajoutant des catégories) et les remplir, mais aussi fixer des valeurs à des champs, quelle que soit l'entité qui a ajouté la catégorie auxquels appartiennent les champs. champs existant (remplis préalablement ou pas).
Les valeurs renseignées par chaque entité n'écrasent données à travers un parent n’écrasent pas les valeurs données des autres, par les autres parents, 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 rajoutent.
> Les catégories rajoutées sont-elles ajoutées globalement à l'objet ou localement comme les valeurs de champs additionnels sur les représentations.
?
> Si globalement, a-t-on un suivi des catégories ?