Misconception: Widgets reinvent the wheel
Posted on:One of the most common misconceptions about the W3C’s Widget packaging format is that it reinvents (or could simply have used) existing packaging formats: namely, Oracle’s Jar format, Mozilla’s XPInstall (XPI) format, or the Open Document Format.
The widget packaging specification tried to overcome obvious limitations and complexity in those formats. For instance, the above formats all require special authoring tools (or make use of complex internal file/folder structures). I say explicitly because the Working Group looked at all the above formats when we were specifying the W3C widgets format. After a long hard-look at each, we concluded that none were fit for purpose.
To show why each one would not make a suitable format:
- JAR: depends on the META-INF directory and defines files designed to load Java-based applications and libraries. Hence it is specifically designed around the needs of Java and the semantics of various aspects of the packaging format that don’t make sense for Widgets.
- ODF: amongst other things, it requires that a special file (‘mimetype’) be found at byte position 38, making it extremely difficult to create a package without a special tool.
- XPI: format (which itself reinvents JAR) makes use of RDF, which is notoriously difficult for developers to learn, read, write, and maintain. Hence, the working group concluded that XPI would make a lousy widget-packaging format. Furthermore, XPIs suffer from versioning issues, which causes them to stop working when Mozilla Firefox is updated.
By contrast, and by design, W3C Widgets require no special tools to make a Widget package. The format is designed to take advantage of Zip tools that have come bundled with all operating systems for at least a decade. The format puts very few requirements on authors: the only two being to include a config.xml (which can be almost empty) and a file to start the application (index.html)[1]. Furthermore, we designed W3C widgets so they were not bound to particular runtimes: in effect, overcoming the issues seen in XPIs and other platform-version-dependent applications.
Other posts in this series:
- Misconception: JSON is easier than XML
- Misconception: XML Digital Signatures is too hard to implement
- Misconception: Widgets lack an origin
- Misconception: Widgets lack a security model
[1] Instructions of how to construct a widget are so simple, in fact, that Opera Software once published all the instructions on a business card.
I’m not sure that the RDF/XML involved in creating an XPI is particularly difficult to learn, write, or maintain. Most install.rdf files in XPI packages look almost like regular namespaced XML. There are weird complications to reading RDF/XML because there are so many ways to express the same thing. If the difficulty reading RDF/XML is a concern, why can’t W3C standardize a subset instead of inventing another new package format?
Re-standardizing yet another format/subset: http://xkcd.com/927/
🙂
A subset of an existing format seems strictly preferable to creating yet another completely independent format for config.xml. At least an implementation that could read an install.rdf file could read the subset. Have you consulted with the RDF WG about concerns regarding the difficulty of RDF/XML?
It sounds to me like it’s not really a misconception that widgets reinvent the wheel, but that you think it will be easier for implementers if they do. This may or may not be correct.
I have not consulted them, but the WebApps Working Group and the Web community at large have reacted quite violently against anything RDF… even XML is an extremely hard sell. See:
http://www.w3.org/community/native-web-apps/2011/10/11/misconception-json-is-easier-than-xml/
Regarding if it’s a misconception or not, I guess only history can be the judge of that.