JSON vs. XML

[wrygiel]

We need to reach a final verdict. We should do so during the Skype meeting on 5th of February, but we may discuss the issue beforehand in this thread.

Key facts

• Recently we have conducted a poll for developers on the technical mailing list. Results from the poll indicate that most developers would prefer JSON as the primary data exchange format in EWP. However, no specific reasons were given. Please discuss here.
• I myself (Wojtek Rygielski, the author of the currently released EWP specifications) have mixed feelings on this subject.
  • I had lots of experirence with XML Schemas, but I do know that many developers don't like them. Many also don't truely understand XML namespaces.
  • I like JSON very much and I prefer to use it when I have a choice, but I didn't have any experience with JSON Schema.
  • I suspect that most developers won't like JSON Schemas any better than they like XML Schemas. One of the reasons people like JSON is because they don't need to care about schemas when using it.
  • I believe having a schema (any schema) will be useful in the project. It makes it easier for developers to validate if their output fits our specifications. And XML Schemas are still much more widely adopted than JSON Schemas.
  • I would cast my vote on option 2b below. Option 1a would be my second choice.
• Michał Kurzydłowski (@Awerin) - other developer from Poland, who is also supposed to prepare Java implementation to be used by other developers - is a supporter of XML. He argues that it will make Java development easier. Perhaps he can elaborate on that matter here?

Decisions to pick from

• 1a. We proceed with XML and XML Schemas. Most of the documentation will be present in the annotation elements within the XML Schema files.
• 1b. We proceed with XML, but keep the primary documentation in Markdown. XML Schema file will also be provided, but without any annotations inside. Developers might skip reading them.
• 2a. We switch to JSON and keep the documentation inside JSON Schema files.
• 2b. We switch to JSON, but keep the documentation in Markdown. JSON Schema files will also be provided, but without any annotations inside. Developers might skip reading them.

[wrygiel]

Georg Schermann wrote:

I think XML is slightly more suitable for the scenario (encryption, signing, file attachments etc.) but we are also good with JSON

Encryption and signing seem to be already taken care of - because we use SSL for all communications. File attachments seem to be equally "doable" in both formats (however I would rather try to have them served at separate URLs than have them embedded - we will discuss this issue in proper time).

[georgschermann]

Id prefer 1(a or b doesn't matter for us) but we are also ok with json

The key benefits over JSON in my opinion are:
easy generation and validation of services, interfaces, DTOs, etc. in Java (and .NET as far as i know)
but maybe this isn't a big impact, since reference implementations would be provided for Java etc.

the wsdl, xmlenc and xmlsig standards which might be handy for our usecases
specially if we want to sign parts of the data by multiple persons, if we only work with signed PDFs and the rest of the data is neither signed nor encrypted (besides SSL) than it doesn't make a difference between json and xml

the broad adoption in development tools and existing best practices
in my personal experience it's easier to build(generate) a client for a well specified xml service than for a json service and the existing knowledge is usually better with xml and there exist best pracitces for encryption, signing, transport security, file attachments, etc.

[wrygiel]

specially if we want to sign parts of the data by multiple persons

I'm not yet sure if this will be one of the use cases, but it's possible - this seems to be a very good point for XML, and also one I haven't thought of before. Thanks!

[mikesteez]

We (Umeå University) prefer option 1a.

In the EMREX project, we think that it has been advantageous to have a schema to validate against. It is beneficial to have a schema that is

a) versionable
b) communicable
c) contains documentation

A schema can also help local developers to validate the output of the application, without access to other nodes. There are drawbacks with XML, but in this case we believe that the advantages outweigh the disadvatages.

I have not seen the poll on the mail list. Am I subscribed?

[wrygiel]

Thanks.

I have not seen the poll on the mail list. Am I subscribed?

I don't have the proper access to verify that, but I'll forward your question to someone who does.

[wrygiel]

During today's meeting we chose XML as the primary format. This should be stated in the next version of the https://github.com/erasmus-without-paper/ewp-specs-management document.