Creating an xml file from xsd in .NET

Question

Hi everyone, I would like to know the best method for solving this problem: I would like to create a blank template xml from a xml schema. All the required elements and attributes would be created and their values would be all empty strings.

The next step is how to determine which child xml nodes a certain node could have. eg. I would select a node has has minOccurs="0", maxOccurs="unbounded" for one of its children. I would be able to determine everything about that child, its attributes, its name, its value type, etc.

To give more context on the situation, I am working on a tool that allows users to edit xml files in a more user friendly setting. For eg, They could add a new account to the 'account db' node and they would see that the only available node is an account node. Next, when they try to add children to the account node and the choices would be name node (required), password node (required), settings node (optional), etc. How do I determine programmatically what children the account node has available to it and what the attributes and settings are on those children?

This is in C# 2.0 with .NET 2.0.

In summary, which classes do I use to read a schema and parse it to get useful information for creating a xml? In my naivety I had hope that since xsd was xml in itself there would be some sort of DOM model that I could traverse through.

I would like this to be confined to my program so no use of external tools such as OxygenXml, VS, xsd.exe, etc.

Answer 1

you can use a third party tool such as XMLSPY (link). it'll make a dummy xml from xsd or vice versa.

A really roundabout (but free) way you could do with .NET tools that exist on your machine would be to use xsd.exe (link) to generate the entity objects that your schema defines using the following:

xsd /classes /language:CS XSDSchemaFile.xsd

Then when you have the objects, load them into a project and serialize them. You can populate properties and such if you want to add some dummy data.

Answer 2

I've been bleeding my eyes out with the MSDN docs and I think I've picked up a scent. Load a schema using XmlSchema.Read and compile it. The Elements property will contain a collection of the 'top level' elements. You'll have to hardcode the qualified name of the root element or something. Then that's it. I haven't found how to find the 'contents' under a given schema element yet.

Edit: I've found some more paths to go but it's still not crystal clear. XmlSchemaElements have a schema type property. This is either simple or complex. Complex types in xml schema can have attributes, sequences, groups, etc. The sequences have a property called particle which can be an element. And the cycle repeats. But I think the hard part in implementation would be to make sure you cover all possible cases (simple type, complex type with attribute, complex type with attribute and elements, extensions, the whole shebang).

Edit: Use the XmlSchema object's Element property to get an XmlSchemaElement. Use the XmlSchemaElement's SchemaType property to get simple or complex type. Use the XmlSchemaComplexType's Attribute property to get attributes or ContentModel to get 'simple content'/'complex content' or Particle to get 'sequence'/'choice'/'all'. Basically a lot of travelling down properties and checking types and casting objects left and right and checking all the possible arrangements of xsd objects. To create a library would be long and cumbersome and error-prone. And this is with xml schemas, with dtds I don't even want to begin thinking. Wow, xml schemas are necessary but why do they have to be so evil.

Answer 3

The solution here will work. It's a little convoluted but it does the job. Please note though, that as each operation involves creating a class, compiling it and serializing it, performance is unlikely to be great.

Oh, and you may have to edit some of the registry entries as it's targeted for v1.1

Answer 4

It sounds like what you want to do is replicated the functionality behind XML intellisense in most good XML Editors. ie read an xml schema and work out which elements and attributes can come next.

We have done something very similar on a project we worked on some time ago. To produce something that works most of the time is a lot of work, to product something that works all the time is loads of work!

Basically you need to load the XSD (the XmlSchema objects in .net allow you to do this). But the SOM object model they expose is very raw, so you need to do quite a lot of work to interpret it. If you ignore concepts like substitution groups, complexType extension, chameleon schemas and namesapces, you should be able to navigate the SOM reasonably easily.

You next need to figure out where you are in the XML document with relation to your schema. Once you known were you are in the SOM you can then start to work out the available options.

To do this properly is 1,000' of lines of code and 4-12 man weeks of work. You may be able to get something basic together in a few weeks?

Answer 5

Thanks a lot. Maybe you'll see my XBRL Taxonomy parser on CodePlex soon.