Séparateurs et horodatage

Il y a deux philosophie de segmentation des données. La première consiste à encadrer les données, par exemple le XML ou le HTML. Chaque texte est encadré. Chaque partie est elle même encadrée. Les parties sont indépendantes et syntaxiquement interchangeables. Les encadrants sont obligatoirement ouverts et fermés. Il est possible de hiérarchiser les informations d’une partie en les plaçant dans des sous-parties incluses dans la partie. Les sous parties peuvent avoir les mêmes encadrants que la partie principale.

La seconde philosophie consiste à séparer les données. On ne délimite plus une donnée mais on marque la fin d’une donnée et donc implicitement le début de la suivante. L’absence de séparateur marque aussi la fin d’une donnée mais dans démarrer une autre donnée. Il existe bien un séparateur dans ce cas aussi mais il marque la fin d’un document… c’est à dire un niveau de données de plus haut niveau. Une hiérarchisation est possible en utilisant plusieurs séparateurs différents.

Cette seconde méthode a des avantages, et pas seulement en place économisée par rapport à des encadrants. Mais elle a comme inconvénient de consommer plus de (caractères) séparateurs.

Dans les liens nebule, la marque de temps à la norme ISO 8601:2004 consomme elle aussi de multiples séparateurs. Il n’est dès lors plus possible de les utiliser comme séparateur au même niveau ou au niveau supérieur. On peut cependant en gagner un, le / de séparation des périodes de temps est invalide pour un lien puisque la marque de temps doit impérativement être ponctuelle. C’est cette marque de temps qui va poser le plus de contraintes sur les séparateurs des liens… sauf à ne pas utiliser cette norme. Éternel débat en fait.

Il reste quand même plusieurs caractères utilisables comme séparateur :
_ / # = * % & @ $ ! ; ~ ( ) { } [ ] < >
Et hors concurrence avec la marque de temps :
- + :

Tout un monde…

Liens de classification des objets

Les objets que l’on affiche dans les applications sont déjà affublés de certains marquages, même si ils ne sont pas encore tous fonctionnels.

Par exemple, un objet peut être marqué comme dangereux et donc son contenu masqué par défaut. Cependant, les enfers n’ayant toujours pas ouverts, ce marquage n’est pas utilisé.

D’un autre côté, un objet protégé se verra affublé d’un message d’avertissement pour prévenir que son contenu ne doit pas être affiché en public. Ou dans certains cas comme sur les messages, c’est un indicateur qui donne l’état de protection d’un message.

Mais il est un autre type de message qu’il peut être utile de délivrer à un utilisateur. Au delà du fait qu’un objet est protégé, cette protection se justifie sûrement par rapport à la sensibilité du contenu de l’objet. Il est alors légitime de préciser une classification du contenu de l’objet dans certaines circonstances.

Cela permet d’avoir aussi une liste des informations importantes et de les tracer plus facilement.

C’est ce que font les militaires pour marquer les documents sensibles et classifiés. C’est ce que font les industriels pour marquer leurs secrets industriels.

La difficulté ici c’est qu’il n’y a pas de marquage type. Chacun emploie ses propres références de marquages. Il faut donc permettre cette souplesse. De plus, les marques doivent s’additionner et non se remplacer.

On peut imaginer un nouvel objet réservé destiné à gérer les marquages et qui servirait comme champ méta dans les liens de marquage. Les liens de marquages, type l, feront le lien entre l’objet à marquer et un objet de marquage via l’objet de référence.
Peut-être que l’objet de marquage sera lui-même aussi un objet de référence de ce marquage en particulier. Ceci permet de gérer des attributs liés au marquage comme un nom long, un nom court, une couleur, etc…

L’étape suivante sera ensuite de faire apparaître les marquages autours des objets. Est-ce géré comme les messages d’information actuels ? Est-ce géré différemment pour être clairement différencié ? Comme sera géré le multi-marquage ?

Enfin, comme ce système de marquage aura un impact sur les performances, il sera activable au besoin mais pas par défaut.

Pour l’instant c’est une idée non encore implémentée…

Copier/coller et marquage

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.