Am I the only one out there, but is the Xml.Schema API one of the worst in the .NET Framework ?
I realize that XML Schemas are not the most friendly of structures. We're not talking about 'at a glance communication' here. But that's a separate topic altogether. The problem is that the XML Schema API doesn't hide any of that nastiness for you, and in fact makes matters worse in some cases. My pet peeves are:
- Why are all classes and types prefixed with XmlSchema? Surely this is the job of namespaces. It makes ugly code and it's tiresome typing that in everywhere you do anything with a schema.
- I don't like APIs that require type casts everywhere. It's great from a framework developer's perspective because all functions just return the base type XmlSchemaObject. This means they can add new classes to their namespace and not worry about changing these base functions or adding new functions. But it's a pain for developers. Each time they use any of these functions they need to check what type the object is, then cast it - usually using a temporary. It looks messy. The Reflection API seems to have addressed this issue with providing helper functions to return the correct typed object. Why can't the Xml.Schema designers follow the same guidelines?
- Some of the names chosen by the developers seem very confusing – there seems to be obviously better ones available. The comments that go with them don't really add much to them either. These names are usually the victim of the above point, for example check the MSDN comments for “XmlSchemaComplexType.Particle“ and “XmlSchemaComplexType.ContentTypeParticle“. And maybe “XmlSchemaElement.ElementType“ and “XmlSchemaElement.SchemaType“. A lot of this has to do with 'post-compilation' - but surely there's a better way to model this?
So as a bit of constructive criticism, what would be nice is to have an XML Schema API that parsed the schema and provided the following:
- List of all types available (named and anonymous – defined inside an element) in the entire schema, at any place in the schema.
- List of all unique constraints in the schema applicable to a given element - regardless of where they were defined. I don’t want to drill down to each element to get some constraints, only to have to check the parent elements for further constraints on the same element.
- List the relationships (keyrefs) in the entire schema applying to any given element regardless of where it was defined. This should include implied relationships between elements where one element is a sub-element of another.
- Provide an easy way to access the schema ignoring types. If element X is defined as type 'XType' and element Y has an anonymous type then expose their definitions in the same way. If I don't want to know how they were declared I shouldn't care, if I do then the information should still be available.
- Access to ‘imported’ or 'replacement' schemas providing all of the above.
- Flatten the API a little. If there's a sequence or a choice just use a collection with a property on that collection. Does it really warrant separate classes? Having an XML element translate to a .NET XML Schema class might make it easier to represent, but it makes it hard to code against.
- Provide helper access properties for the most common types. Also provide helper collections for the same. Follow the example of the Reflection API.
I realize most of the above could be done with a wrapper class, but XML Schemas seem such a vital part of the web service infrastructure I would have thought it would have a good API backing it up.