Discussion :

[Hibou57]

Coucou les potes et les potines,

Je me renseignais sur les attributs les plus standardisés en XML.

Il y a bien sûre les fameux HREF (peut-être inspiré d'HTML, à moins que ce ne soit d'SGML), le tout aussi célèbre NAME (qui a probablement la même source que HREF), et enfin le couple ID/IDREF, dont il est même question dans la référence XML du W3C (donc c'est du standard de chez standard ces deux là).

Quels sont les attributs les plus standards pour les dates ?

Je pense à last-modified et à creation-date... mais sont-ils vraiment standards ?

Existe t-ils d'autres attributs standards de-facto que j'aurais oublié ?

Existe t-il quelque part un dépot de ces attributs ? Un liste ?

By the way : avec quel attribut fait-on référence à des attributs NAME ? (je veux dire, quel est l'attribut qui est à NAME, ce que IDREF est à ID)

-- EDIT (m-à-j 31/07/2007)

• creation-date (standard de-facto)
• date (standard de-facto)
• href (inspiré d'HTML et utilisé dans XLink - voir aussi xml:link)
• id (exposé dans le standard xml, entre autre)
• idref (fonctionne avec id)
• lang (exposé dans le standard xml)
• last-modified (standard de-facto)
• link (voir xml:link)
• name (standard de facto, ne semble pas avoir d'attribut réciproque)
• role (fonctionne avec xml:link et href)
• xml:link (peut être renomé, car dans un espace de nom)

-- FIN DE L'EDIT

Marci

[fraoustin]

si tu mets de côté idref, il n'existe pas de "norme" pour les attributs comme pour les noms de balise. En faite un des objectifs de l'XML est justement de dire aux développeur : utiliser votre vocabulaire et si vous pensé qu'il va exister des doublons utiliser les namespaces.
Maintenant , pour ma part échangeant de nombreux document Xml avec plusieurs fournisseurs ou clients, je préfère utiliser des termes anglais, sans accents sans caractères spéciaux du genre "-" et sans majuscule

voila @+

[Hibou57]

[...] pour ma part échangeant de nombreux document Xml avec plusieurs fournisseurs ou clients, je préfère utiliser des termes anglais, sans accents sans caractères spéciaux du genre "-" et sans majuscule
voila @+

Pourtant des name-token avec - _ : et . ne devrait pas poser de problème. Il suffit de n'utiliser que les lettres ascii (ce qui est effectivement une bonne condition). Dans quelles types de circonstances les - _ : et . peuvent poser problème ? Je suis curieux... j'ai besoin de savoir.

Sinon, il y a quand-même des attribut standard, si, et les noms d'attributs ne fonctionnent pas comme les nom d'éléments, qui eux, sont libres, indeed.

Ainsi par exemple y at-il l'attribut xml:link, qui identifie un élément comme étant un XLink. Les XLink ne sont pas reconnus comme tels par le nom de l'élément, mais par la présence de cette atttribut. xml:link étant dans un espace de nom, il peut bien sure être utiliser comme link tout court, ou être renomer.

Ensuite, il y a l'atttribut « role » qui vient directement avec.

Et j'ai par ailleur oublié l'attribut « lang » (honte à moi)

Tant pis s'il n'existe pas de liste tout faite... on va la faire ici (on est bien là pour construire des choses utiles, n'est-ce pas ? )

Je les ajoute au premier post.

[fraoustin]

Pour compléter ma réponse:

Dans quelles types de circonstances les - _ : et . peuvent poser problème ? Je suis curieux... j'ai besoin de savoir.

je n'ai pas écrit que cela posait problème, mais si tu ne souhaites que avoir les codes ascii avec un grand nombre de fournisseur il vaut mieux avoir des règles simples d'ou le

je préfère utiliser des termes anglais, sans accents sans caractères spéciaux du genre "-" et sans majuscule

Et pour xml:lang, xml:link, ... se sont des attributs spécifiques

[Hibou57]

[..] si tu ne souhaites que avoir les codes ascii avec un grand nombre de fournisseur il vaut mieux avoir des règles simples d'ou le

Oui, je comprends trés bien. Et je recherche moi-même aussi certaines formes de simplifications, dans le même but, même si j'ignore encore si client(e)s il y aura

Je pense que ces restrictions volontaires sont assez fréquentes... ce qui contribue à une meilleure simplification encore d'XML, qui est déjà simple en mui-même. C'est plutôt une bonne chose.

En tous les cas, ça évite d'avoir à expliquer des choses aux client(e)s, qui même si à nous elles nous parraissent simple, sont pour eux/elles loin de ce avec quoi ils/elles ont envie de traiter.... ça évite les mauvaises surprises, surtout techniques, qui sont celles qui passent le plus mal.