[Core] XML output validation + Schema

[Frans]

XML output validation and XML Schema needs improvement.
Also on the todo-list is a description of the complete XML output.

[Frans]

Tom K. could be helpfull here...

[peter]

4 hours are estimated to look for the best solution. In this release the schema's will not be realized. So these hours are a spyke.

[UvA - Tom]

Hi Robert,

After reading the spike document I've got a few remarks and suggestions. I think the intent to setup a XML schema is most important. The primary objective should be to come up with a schema for developers to use as a contract. A contract to program against the REST interface. Both parties, mediamosa and external developers, should respect it. And if they do they should be able to communicate successfully. By referring to the contract (schema) it's always clear on which side a problem should be fixed. Output validation is not the main goal, although it's absolutely necessary of course.

In paragraph 2.1 you suggest using a DTD, but I strongly suggest XSD. XSD is the successor of DTD and especially designed to describe XML documents. XSD is XML itself, it makes sense to specify the structure of a piece of XML in XML. XSD has build-in data-types like string, int, date etc. See  http://nl.wikipedia.org/wiki/XML_Schema_Definitietaal (or  http://en.wikipedia.org/wiki/XSD).
XSD has broad tool support (XMLspy, Oxygen) and is used for code generation in Java, C# and other languages. Code generation is an important aspect of specifying a schema. The code generated based on the XML schema is a model and a representation of the mediamosa responses in a specific programming language.

In paragraph 3 you describe options for extending the REST output with XML schema validation. I would advise to setup the schema first. Based on that, check if the output XML is valid. It's no use generating a schema on XML output. It seems if you're trying to come up with a schema which matches to exiting XML output. But the schema should be the starting point.

In paragraph 3.1 you refer to unit-testing which is a very good idea. But you want to see if the XML is valid compared to the schema. You wrote "see the DTD does match expected output". I believe it should be exactly the other way around: unit-test to see is the output (XML) matches the XML schema. Don't match the schema on the XML, but match the XML on the schema.

In paragraph 3.2 I believe the problem you're trying to solve is linking a piece of XML to its schema definition. This is done with namespaces in XML (namespaces and schemalocations). An XML document can contain a schemalocation which is a reference to the XSD document. This XSD describes the structure of the XML document. Your concern about clients choking on links or comments in XML are not grounded in my opinion. As long as the responses are valid and well-formed XML you shouldn't worry about clients. It's still XML, and the responsibility of the client to process XML (I believe the underlying problem with these kind of client applications is they treat the incoming XML simply as text not as native XML.)

In paragraph 3.2.1 the attribute "standalone" is mentioned. The optional attribute "standalone" is only relevant for DTD's. Current applications will not likely check the attribute. When using an XSD the attribute is not needed and ignored.

Maybe we can discuss this further in a face to face meeting if things are unclear.

Grt, Tom

PS: does this get reopened?