Configuration XML dégoûtante sans schéma - pourquoi?

Question

Il ne s'agit pas de savoir pourquoi XML est utilisé pour les fichiers de configuration. Ma question est pourquoi, quand XML est utilisé pour les fichiers de configuration, il n'y a pas de schéma d'accompagnement.

log4net est un bon exemple de cas. Vous pouvez le configurer par programme, mais il est préférable d'utiliser XML. Bien, mais alors pourquoi est-ce que ça doit être si dur?

Dans Visual Studio lorsque je suis en train de taper XML avec un schéma, je reçois Intellisense comme je vais. Sans un, je dois deviner chaque élément et chaque attribut, car il ne semble jamais y avoir une liste complète. Le XML devient Disgusting XML, le type qui est sujet aux erreurs et fastidieux à taper.

Ceux d'entre vous qui ont travaillé sur de tels projets: Pourquoi les libérez-vous avec de la documentation et des commentaires et des échantillons XML, mais pas de schéma XML pour faciliter la configuration? Est-ce la paresse? Y a-t-il un motif véritable derrière tout cela? Est-ce que personne n'y a pensé?

Answer 1

Je pense que la raison principale est que, dans la plupart des cas, vous mettez déjà vos attentes sur ce que vous attendez d'un document dans le code qui évalue le xml. Par conséquent, un schéma pourrait être vu comme un travail supplémentaire. Et même dans le travail open-source n'est pas gratuit ...; D

Answer 2

Je crois que, alors que la plupart des développeurs comprennent assez bien le XML, et avec cette connaissance, ils peuvent construire des programmes qui lisent les fichiers de configuration XML, les schémas XML ne sont pas presque aussi bien compris.

Cela est probablement aggravé par le fait que la plupart des outils d'écriture de schémas XML coûtent beaucoup d'argent, ou sont disponibles gratuitement, mais pas très bons ou agréables à travailler. Il devient alors juste un peu plus difficile d'expérimenter sérieusement les schémas XML.

(Je sais, bien sûr, un éditeur de texte devrait être suffisant pour écrire XML et XSD. Mais il est souvent une différence cruciale si des outils spécialisés sont disponibles ou non, à mon humble avis.)

Answer 3

Nah, je Je ne vais pas m'embêter avec un XSchema parce que le standard est maladroit, inflexible, et ne fournit rien au-delà de la validation syntaxique typée de base. Cela me permet donc de définir une grammaire pour le fichier et des types de données de base pour les valeurs, mais je vais quand même devoir écrire mes propres routines de vérification pour tous les paramètres non triviaux. Même alors, l'impossibilité de définir mes propres formes lexicales, ou de définir mes propres restrictions ou extensions de types de données xsd de base au-delà des contraintes de base, rend la spécification incapable d'exprimer les formes syntaxiques nécessaires pour la validation syntaxique. Il suffit de considérer comment vous pourriez déclarer que le texte() d'un élément doit être un ISBN valide? Ou un nom de fichier/chemin de répertoire valide? Ou un nombre premier? Ou une année bissextile? etc? etc? etc?

Personnellement, je pourrais vous fournir une DTD si vous êtes chanceux (c'est-à-dire un EBNF non typé dans un format bizarre). Je pourrais même lancer un convertisseur DTD automatique sur RelaxNG et nettoyer le résultat pour vous. Mais ne vous attendez pas à ce que j'écrive un schéma. Si je veux fournir un vrai support de validation, vous n'obtiendrez pas de XSchema de toute façon; Je vais plutôt vous remettre GRDDL + OWL, où entre XSLT et la puissance d'un langage de contrainte FOL déclaratif, je peux effectivement déclarer des validations qui valent la peine d'être faites.