Après deux semaines et 721 messages, le
débat qui semble avoir
écarté la voie médiane de l'"absolutisation" rebondit sur une
"proposition à moitié sérieuse"
.
Par Eric van der Vlist,
Dyomedea (vdv@dyomedea.com).
lundi 29 mai 2000
Paul W. Abrahams revenant aux sources rappelle
la signification première des URIs utilisés par les espaces de noms :
"OK, les gars qui ont mis au monde les espaces de noms le disent :
les noms des espaces de noms ne veulent rien dire. Ce ne sont que des
identifiants uniques."
et David Carlisle rappelle
les raisons pour lesquelles les URIs ont été choisis comme identifiants
pour les espaces de noms :
"Il est clair que quelque chose de plus similaires aux noms de packages Java
ou aux FPI aurait évité beaucoup de ces discussions mais chacune de ses solutions
présentait des inconvénients : les noms Java exigent d'avoir déposé un domaine tandis
que les URIs ont été (c'est ce que l'on nous a dit sur xml-dev) choisis volontairement
comme un mécanisme permettant quiconque disposant d'une adresse email auprès d' un
fournisseur gratuit de ce constituer un espace de nom. Les FPI auraient été une bonne
solution mais obtenir un FPI officiel est pratiquement impossible.
La décision d'utiliser des URIs a donc été prise pour les noms d'espaces de noms,
il est évident que d'autres décisions auraient pu être prises, que d'autres
principes de nomages pourraient être utilisés, mais c'est du domaine de l'histoire."
Clark C. Evans reconnait que :
"Puisque, de mon point de vue, il semble y avoir deux camps :
a) Ceux qui croient qu'un nom d'espace de nom ne devrait être utilisé que pour l'identifier et rien de plus.
b) Ceux qui croient qu'un nom d'espace de nom devrait aussi être utiliser pour localiser en plus d'identifier."
Evans propose de différencier ces deux utilisations
au moyen des schémas URI (data: pour l'identification et http: pour la localisation) et
Tim Bray va plus loin et suggère de généraliser la seconde forme :
"En fin de compte, il n'y a que deux positions cohérentes à
propos de la comparaison et de l'équivalence des noms d'espaces de noms :
1. la comparaison octet par octet de l'espace de nom comme il est écrit
2. la comparaison octet par octet de le ressource indiquée après l'avoir chargé.
Toutes les positions intermédiaires sont à mon avis fatalement compromises.
#1 a l'avantage d'être moins chère et de demander moins d'infrastructure. #2 a
l'avantage de connecter réellement et profondément les espaces de noms au web
d'une manière cohérente avec l'architecture quelqu'elle soit. S'il y avait une
recommendation W3C sur ce que le déréférencement devrait être (je recommande un
document présentant un XLink unique (éventuellement complexe)), je pourrais être
enthousiaste."
Cette proposition est contrée par Simon St. Laurent qui met en
avant les problèmes de ressources mises en jeu :
"Je dois protester contre cette suggestion en raison de
l'infrastructure nécessaire pour traiter un nom. Les
ressources en mémoire cache seraient énormes et pourraient
bien ne pas exister. Expliquer tout cela aux gens qui tentent
d'utiliser XML sur des PDSs ou même sur des périphériques
encore plus petits (ce qui était un des buts explicites de XML 1.0)
semble demander bien du courage."
Parallèlement, dans un autre échange de messages,
John Cowan propose
de séparer les notions de nom d'espace de nom et d'URI lié à un
espace de nom en rajoutant "data:," au nom pour obtenir l'URI. Il rappelle
également que les URIs des espaces de noms sont importants pour RDF non
seulement en tant que pointeurs, mais également comme référence pour
pouvoir considérer les espaces de noms comme objets RDF, ce que respecte
sa proposition :
"les espaces de noms sont des ressources ayant des URIs et peuvent
donc toujours être sujets et objets d'instructions RDF, même s'ils n'ont plus
les mêmes URIs qu'auparavant."
Copyright 2000,
Eric van der Vlist.
|
