J’ai dérivé un modèle Opale 3.6 et j’y ai supprimé les métadonnées concernant les licences CC (sp:cc et sp:ccVersion).
Quand j’applique le xsl de migration à un atelier réalisé avec une dérivation opale 3.5 dans laquelle les métadonnées cc et ccVersion sont renseignées sur un module par exemple, les nœuds sont bien supprimés mais les items apparaissent toujours en défaut.
pour supprimer le défaut, il faut que j’aille dans l’onglet « édition », que je sélectionne le bloc « métadonnées » et que j’efface (alors qu’il est vide), le module apparait alors sans erreur dans l’explorateur mais toujours avec une erreur dans la partie droite de scenari (alors qu’il n’y a plus d’erreur dans l’onglet infos).
je suis obligé de fermer l’atelier et de le rouvrir pour que l’erreur disparaisse.
j’ai remarqué que le XML conserve le noeud sp:info/op:info. Quand je supprime ces nœuds, l’erreur disparait dans l’explorateur et il faut que je rafraichisse le module pour que l’erreur disparaisse également dans la partie droite de scenari.
est-ce que quelqu’un a déjà rencontré ce problème ??
Bonjour Jean-Paul,
Je bosse également en ce moment sur des migrations de modèles avec XSL. J’ai réncontré et rencontre également un souci de nature similaire.
J’ai réussi à enlever une partie des erreur. Dans ma XSL j’avais sans contrôlé l’existence de l’attribut sc:id sur certains éléments lancé une commande type
<xsl:attribute name=« sc:id>xsl:value-of select= »<@sc:id"/></xsl:attribute>
Or évidemment quant l’élément d’origine n’a pas d’attribut sc:id, celui ajouté est vide et Scenari grince des dents. J’ai ajouté un <xsl:if… pour tester la présence de l’attribut et ça a corrigé les items concernés.
Par contre, j’ai également certains items qui apparaissent en erreur et pour lesquels la simple édition du titre puis enregistrement corrige l’erreur. J’ai jeté un oeil rapide au XML avant et après. Ce qui me saute aux yeux c’est la déclaration des namespaces à des endroits différents selon que le fichier est issue directement de la migration ou de la réécriture par ScenariChain. Je n’ai pas essaye de les remettre à la main aux « bons » endroits, mais je soupçonne ça.
Ce qui est étrange c’est que ça le fait sur certaines transformations seulement. Si j’ai tel contenu avant migration alors ça le fera et pour tel autre non. Donc ça laisse également à penser que le bout de xls correspondant est responsable de l’erreur.
Du coup je suis également preneur de vos avis.
Merci pour tes infos, mon problème est en partie résolu. ça venait effectivement des balises info qui ne respectaient pas le bon schéma. il me reste un problème similaire au tien au niveau d’une activité d’auto évaluation internalisée qui est en erreur et dont l’erreur disparaît quand je change le titre. Je te fais signe si je trouve.
J’ai trouvé la solution à mon problème. Pas encore eu le temps de vérifier tous mes items sur la migration mais en tout cas c’est ok sur un échantillon.
Voilà ce que j’ai trouvé :
Ma migration partait d’un modèle « maison » vers de « l’opale like » et sur les items de ressources j’avais oublié d’ajouter systématiquement op:resInfoM/ dans les balises sp:res pour les ressources sur lesquelles je n’ai pas de fichier de metadonnées.
J’avais après migration <sp:res sc:refUri=« … »/> au lieu de <sp:res sc:refUri=« … »>op:resInfoM/</sp:res>, ce qui génère effectivement une erreur vis à vis du modèle qui impose une balise méta même vide.
J’ignore si ton souci est du même style mais ce qui est intéressant c’est la méthode pour retrouver.
Je lance la migration sur mon contenu
Je trouve des items marqués en erreur mais dont on ne retrouve pas d’erreur en parcourant la liste
Je duplique l’item dans Scenari pour garder l’original
Je change le titre de la copie et ça corrige l’item, donc je suis bien dans mon problème à corriger
Je fais un diff entre les deux items (l’original et la copie corrigée). Pour améliorer la lisibilité j’ai utiliser un éditeur XML qui peut refaire l’indentation avant de faire le diff entre les 2 fichiers. Et là bingo ! j’ai repéré le souci
Ca n’a rien de fantastique mais ça aide à trouver le problème.
Bonjour Franck,
Une autre approche pour trouver les incohérences de la structure de donnée produite par rapport au schéma de l’item est d’exploiter les relaxNg avec un système de validation XML (ex : oxygen).
Antoine
Kelis