Disgusting XML configuration with no schema - why?

Question

This isn't a question about why XML is used for configuration files. My question is why, when XML is used for configuration files, there's no accompanying schema.

log4net is a good case-in-point. You can configure it programmatically, but it's preferred that you use XML. Fine, but then why does it have to be so hard?

In Visual Studio when I'm typing XML with a schema, I get nice Intellisense as I go. Without one, I'm having to guess at every element and attribute, since there never seems to be a comprehensive listing. The XML becomes Disgusting XML, the kind that's error-prone and tedious to type.

Those of you who've worked on such projects: Why do you release them with documentation and XML comments and samples, but no XML schema to make configuration easier? Is it laziness? Is there a genuine motive behind it? Did no one think of it?

Answer 1

I think the main reason is, that in the most cases you already put your expectation about what you expect in a document in the code that evaluates the xml. Therefore a schema could be seen as extra work. And even in open-source work is not for free... ;D

Answer 2

I believe that while most developers understand XML quite well, and with that knowledge they can build programs that read XML configuration files, XML schemas aren't nearly as well understood.

This is probably made worse by the fact that most tools for writing XML schemas either cost a good bit of money, or are freely available, but then not very good or nice to work with. It then becomes just a little bit more difficult to seriously experiment with XML schemas.

(I know, of course a text editor should be enough for writing both XML and XSD. But it often makes a crucial difference whether specialized tools are available or not, IMHO.)

Answer 3

Nah, I'm not going to bother with an XSchema because the standard is clunky, inflexible, and doesn't provide anything beyond basic typed-syntactic validation.

So it allows me to define a grammar for the file, and basic datatypes for the values, but I'm still going to have to write my own verification routines for any non-trivial parameters. Even then, the inability to define my own lexical forms, or define my own restrictions or extensions of basic xsd datatypes beyond basic range constraints, renders the spec incapable of expressing the syntactic forms I would need to make it truly useful even for syntactic validation.

Just consider how you might declare that the text() of an element should be a valid ISBN? Or a valid filename/directory-path? Or a prime number? Or a leap-year? etc? etc? etc?

Personally I might provide you with a DTD if you're lucky (ie. an untyped EBNF in a weird format). I might even run an automatic DTD to RelaxNG converter over it and clean up the result for you. But don't expect me to write a schema. If I'm wanting to provide true validation support, you won't be getting an XSchema anyway; rather, I'll be handing you GRDDL+OWL, where between XSLT and the power of a declarative FOL constraint language, I can actually declare validations that are worth doing.