views:

68

answers:

2

I have a large XML schema that has elements that look like this:

<xs:element name="Tmats">
    <xs:complexType>
        <xs:sequence>

            <xs:element name="ProgramName" type="xs:string" minOccurs="0">
                <xs:annotation>
                    <xs:documentation>PN</xs:documentation> 
                </xs:annotation>
            </xs:element>

            <xs:element name="TestItem" type="xs:string" minOccurs="0">
                <xs:annotation>
                    <xs:documentation>TA</xs:documentation> 
                </xs:annotation>
            </xs:element>

To use it effectively, I need an association between the element name attribute, and the documentation element, as in:

TestItem <==> TA

My first thought was that the elements should have attributes to capture the documentation elements, like this:

public partial class Tmats
{
    [Documentation("PN")]
    public string ProgramName { get; set; }

    [Documentation("TA")]
    public string TestItem { get; set; }
}

...but I am concerned about performance, as these attributes will be scanned pretty extensively during normal usage.

I took a first stab at creating C# classes using XSD.EXE, but that tool doesn't appear to capture the annotation elements at all. Plus, the code it creates is pretty ugly.

Suggestions? Is there a better way to approach this?

A: 

Tough question. You say the schema is large. Hoe often do you anticipate it changing? Hand coding the C# version can be tedious, but if it is not anticipated to change much, then you will get the interface you desire as you are the one coding it. However, if it has the opportunity to change frequently, that will require frequent updating to you mapping and an extensive unit test suite to ensure you do not break anything in your updates.

What I have done in the past is to use the XSD tool to generate the initial code, and then either extend from the generated classes, or make it a partial class to fix the interface to my liking. Not ideal by any mean, but it gave me the ability to generate most of the code, yes, ugly, but generated, and tailor the interfaces that I cared about to make them a little more friendly and add any error/bounds checking that might be useful.

Rob Goodwin
It won't change much, but it represents a standard, so it would be nice if it could just be imported rather than patched.
Robert Harvey
+1  A: 

You will probably have to write your own xsd.exe replacement. AFAIK xsd.exe doesn't support <xs:annotation> elements.

A fairly decent blog describes how to write your own xsd-based code generator (it's medium complexity, btw, and based on my personal experience there's no need to build it too generically):

http://blogs.rev-net.com/ddewinter/2008/09/28/generate-serialization-classes-as-part-of-your-build-part-2/

Note: in the blog entry the <xs:annotation> node is consumed to generate documentation via CodeDOM. Naturally you can generate something else which better meets your needs.

code4life