How about you just save the xml to a file, and use xsd to generate C# classes?
- Write the file to disk (I named it foo.xml)
- Generate the xsd:
- Generate the C#:
xsd foo.xsd /classes
Et voila - and C# code file that should be able to read the data via
XmlSerializer ser = new XmlSerializer(typeof(Cars));
using (XmlReader reader = XmlReader.Create(path))
cars = (Cars) ser.Deserialize(reader);
(include the generated foo.cs in the project)
If you use an appropriate class or library, they will do the escaping for you. Many XML issues are caused by string concatenation.
XML escape characters
There are only five:
Escaping characters depends on where the special character is used.
The examples can be validated at the W3C Markup Validation Service.
The safe way is to escape all five characters in text. However, the three characters
> needn't be escaped in text:
The safe way is to escape all five characters in attributes. However, the
> character needn't be escaped in attributes:
' character needn't be escaped in attributes if the quotes are
" needn't be escaped in attributes if the quotes are
All five special characters must not be escaped in comments:
<!-- "'<>& -->
All five special characters must not be escaped in CDATA sections:
All five special characters must not be escaped in XML processing instructions:
<?process <"'&> ?>
XML vs. HTML
HTML has its own set of escape codes which cover a lot more characters.
org.w3c.domhas no support for XML Schemas. For JDom, you can use schemas to validate a document, but there is no support to build documents.
You have two options:
Use JDom to read the schema, analyze it and produce a document according to this XML document (a schema is always a valid XML document, too).
You can use an XML mapper like Castor. Castor can read a Schema and produce a set of Java classes that allow you to produce documents which match said schema.
The latter approach might not work so well in your case since Castor will generate different Java classes for similar XSD structures unless they are defined in the same document, so you can't easily reuse the common code. The workaround is to let Castor generate the code and then write a script or similar to copy/merge the common parts of the XSDs into the same Java package.