Talk:Efficient XML Interchange

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing (assessed as Low-importance).
	This article has been marked as needing an infobox.

Internet Low‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Low	This article has been rated as Low-importance on the project's importance scale.

EXI4JSON was nominated for deletion. The discussion was closed on 18 September 2016 with a consensus to merge. Its contents were merged into Efficient XML Interchange. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here.

Notability[edit]

I think that this article satisfy the notability guidelines:

it is a W3C draft about an important subject in the XML technology: the definition of a binary XML format
there are a lot of companies in the working group: Siemens, Fujitsu, Sun Microsystems, Intel, Nokia, Adobe, IBM, etc... which shows the importance of the subject for these companies. Hervegirod 21:15, 17 July 2007 (UTC)[reply]

I agree. I'm removing the notice. —Pengo 22:54, 17 July 2007 (UTC)[reply]

Note that it was added before the first draft was published and at a very early stage of the article [1] —Pengo 23:35, 17 July 2007 (UTC)[reply]

Encoding and decoding speeds are both improved with Efficient XML[edit]

Please see [2]Frank Hileman (talk) 16:46, 2 October 2009 (UTC)[reply]

Other solutions[edit]

Please elaborate on how EXI compares to other solutions, such as XMill, XGrind or XQueC. — Preceding unsigned comment added by 83.5.159.151 (talk) 12:06, 1 August 2011 (UTC)[reply]

Why was most implementations removed? Including every C/C++ implementation?

This makes EXI seam disadvantageous compared to other Binary XML formats that have more listed implementations.

Also the text was changed stating that two implementations exist, which is not true. I do understand that Wikipedia is not a dictionary, but this statement makes me think that the other implementations was removed by some other reason. — Preceding unsigned comment added by 188.126.90.83 (talk) 17:04, 3 November 2011 (UTC)[reply]

With regard to the two questions presented above The implementations that exist for C and C++ are faulty. The only solution I have seen in two years that actually works is EXIficient. And EXI isn't only disadvantageous, it's a downright awful binary representation. Nobody uses this standard because the supposed "specification" for it, is incomplete. I've reversed engineered the entire standard myself and my conclusion is that it will never be used except by corporations trying to corner a market by making an incomprehensible and very difficult to encode/decode communication format. As a professional engineer that has had to deal with this for two miserable years because a committee of academic morons have imposed it upon people implementing the DIN and 15118-2 standard, I strongly suggest you use basically anything else, if you have a choice. XML itself is a poor standard, there are no tools that will even validate that an XSD is grammatically correct. Beyond that EXI also doesn't allow anything other than UTF-8, and probably never will, because it will have lukewarm adoption at best. — Preceding unsigned comment added by 12.94.93.158 (talk) 22:47, 29 June 2018 (UTC)[reply]