SPIP dit que c'est un titre, un sous-titre, un chapeau, un contenu, etc.
D'autres CMS ont une conception légèrement différente.
D'autres CMS (Lodel par exemple) n'imposent pas leur définition et proposent de définir un modèle éditorial (liste de types de "documents" à publier et de leurs champs respectifs).
La valeur ajoutée de chaque CMS vient de la façon qu'il a de structurer et de gérer l'information. Imposer un socle commun leur ferait à mon avis perdre beaucoup d'intérêt car ils les empêcheraient de remplir les besoins pour lesquels ils ont été conçus.
Imposer un meta-modèle de données à la Lodel à un CMS simple et rapide comme SPIP n'aurait aucun intérêt. Impoer un modèle de donnée standard et figé à Lodel n'aurait aucun intérêt.
Je crois qu'une solution envisageable serait de concevoir une DTD XML (ou d'en réutiliser une comme TEI) suffisament vaste pour englober tous les besoins.
Le problème ne serait pas pour autant résolu :
- comment un CMS doit-il regrouper des informations dans un seul champ de sa base ?
- que faire des informations du document XML qui n'ont pas leur place dans le modèle de donnée du CMS ?
- comment résoudre la perte d'information d'un document importé puis exporté par un CMS donné ?
# Je suis contre
Posté par dinomasque . En réponse au journal Normalisation des tables des blogs/CMS ?. Évalué à 3.
SPIP dit que c'est un titre, un sous-titre, un chapeau, un contenu, etc.
D'autres CMS ont une conception légèrement différente.
D'autres CMS (Lodel par exemple) n'imposent pas leur définition et proposent de définir un modèle éditorial (liste de types de "documents" à publier et de leurs champs respectifs).
La valeur ajoutée de chaque CMS vient de la façon qu'il a de structurer et de gérer l'information. Imposer un socle commun leur ferait à mon avis perdre beaucoup d'intérêt car ils les empêcheraient de remplir les besoins pour lesquels ils ont été conçus.
Imposer un meta-modèle de données à la Lodel à un CMS simple et rapide comme SPIP n'aurait aucun intérêt. Impoer un modèle de donnée standard et figé à Lodel n'aurait aucun intérêt.
Je crois qu'une solution envisageable serait de concevoir une DTD XML (ou d'en réutiliser une comme TEI) suffisament vaste pour englober tous les besoins.
Le problème ne serait pas pour autant résolu :
- comment un CMS doit-il regrouper des informations dans un seul champ de sa base ?
- que faire des informations du document XML qui n'ont pas leur place dans le modèle de donnée du CMS ?
- comment résoudre la perte d'information d'un document importé puis exporté par un CMS donné ?
BeOS le faisait il y a 20 ans !