W3C Widgets: Yet another XML-in-ZIP file format?

Looks good

By Rick Jelliffe
September 20, 2009 | Comments: 11

From the horse's mouth:

Widgets are client-side applications authored using Web standards. They are downloaded and installed on a client machine or device where they can run as stand-alone applications outside of a Web browser. Examples range from clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be "mashed-up" and presented to a user in some interesting and useful way.

The format is a basic ZIP archive, allowing DEFLATE compression only and W3C signatures. There is an XML document /config.xml that acts as the manifest. It can nominate a start file otherwise /index.* is used. Various icon formats are allowed. SVG has a lot of prominence. The widget can run in several screen modes; I guess they have some connection with HTML 5's canvas element, but I missed any text about this. There is a hook mechanism called feature with which Widgets can access arbitrary runtime APIs.

There is quite a lot off attention paid to localization, to allow widgets in multiple languages; there is a disclaimer that it the ITS related capabilities may disappear. Bundled resources make it easier to bring a stable or centrally-managed resource up to scratch for international use; however, where the resource is evolving you don't want to the internationalization to be out-of-synch.

The drafts looks good and the idea certainly is good: the main one is now at Candidate Recommendation stage.

It will be interesting to see how big a widget can get: can it be a full word processor? And what makes widget so different from applets apart from no Java?

One aspect that particularly interests me for any new XML-in-ZIP-based standard is whether it conflicts with the other ones: I don't see that the Widgets spec does conflict which is good. But if it does not harm, it does not good either, as far as promoting convergence is concerned.

If we ever see an XML-in-ZIP standard that can be used to harmonize ODF, OOXML, Widgets, JAR/WAR/EAR, IDML, SCORM, etc. it won't be suffering from premature standardization.

(I note that they give the wrong spec for RELAX NG: they use the Compact Syntax which is officially available for free on the WWW from the public ISO site.)


You might also be interested in:

11 Comments

Hi Rick,

can you please clarify what relationship you're seeing to canvas? Canvas can be used inside HTML documents that are inside widgets, but there is no direct relationship, I'm unsure which part of the spec you get that idea from.

I don't believe there's a disclaimer that localisation might disappear. Support for ITS (which is a specific part of the I18N support) is at risk, but that doesn't threaten localisation.

One big important difference with applets is that it is intended to reuse the Web stack, instead of doing something insular that doesn't play well with others. Besides, no Java is naturally a big selling point on its own.

The reason Widgets Packaging and Configuration is a standalone document is precisely because it could be reused by others (as could other parts of the widgets family, e.g. DigSig). I don't know if there would be great value in harmonisation here, but it certainly is possible.

When you say "the wrong spec for RELAX NG" do you mean in the references?

Robin: Yes there is nothing in the spec, hence my comment. Is the idea that Widgets can only run outside a web-browser? If I did have, say, a calendar widget that you wanted to embed in a page as an object, which markup would I use: hence the query about canvas.

ITS: thanks for the clarification.

Yes. The Reference is to the OASIS spec which is the full XML syntax only. The Compact Syntax is the more convenient DTD-like one that Widgets uses. The 2008 version of the ISO standard is the most recent; it has both the updated version of the XML syntax and the compact syntax consolidated.

So I guess a better reference would be:

<dt><dfn id="relaxng">[RelaxNG]</dfn></dt>
<dd><a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip">
<dd><a href="http://relaxng.org/spec-20011203.html"><cite>RELAX NG
Specification,ISO/IEC 19757-2:2008 Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG.</cite></a>, J. Clark (Ed.) and M. Makoto (Ed.), JTC1 SC34 International Standard, 2008.</dd>

Rick,

ah, I understand your question now. No, widgets don't have to run only outside of a browser, they could certainly run inside as well. Where they are made available is really up to implementers. So long as they are not granted access to specific device APIs there is no security issue with running them in a Web context; once they do have access to such APIs (through the work of the DAP WG notably) then we'll need the security mechanisms to match — but we'll cross that bridge later.

Re the reference: thanks, I'll prod the editor to change it. If you have five minutes to take a look at the schema it'd be welcome. I made a pass fixing issues and making it extensible but my RNC has become rusty!

why not just standardize one of the existing {Apple, Google, Yahoo} widget formats?

Guy: You can see the members of the group at W3C that is developing this at http://www.w3.org/2000/09/dbwg/details?group=42538&public=1

This includes people from Google and Apple, but obviously Opera and Vodafone are driving this to some extent, since the editors come from them. I suppose that Apple doesn't need it, since it has its own app environment already.

Guy, there are literally dozens of existing widget formats out there. When the work started the group did a lot of research into the various available options (some of it documented here: http://www.w3.org/TR/widgets-land/). None of them had enough market traction on its own to justify supporting it against the others. Also, they all had quirks. It was globally much simpler to just pick the best of the existing ideas and move ahead with that.

Furthermore, Apple has been fairly aggressive in trying to use its patents to prevent the WG from making progress, so it probably wouldn't have been possible to start with their option.

Robin: Thanks for the useful link.

It looks like W3C Widgets is pretty much taken from the Opera format with its localization gap filled in by doing what everyone else does.

Of course, the file format is only one aspect.

There is definitely a strong Opera heritage, but to be honest so many details were tweaked and changed over time that the two are now fairly far apart (sometimes on behaviour and not in syntax).

Hi Rick, I've updated the spec to use the correct RelaxNG reference; thanks a lot for that! The correct version will appear in the next published draft.

WRT Opera's format, the specs are only loosely related, fairly incompatible, and any overlap is coincidental (I worked independently on the spec for 3 years before joining Opera Software).

What do you mean when you say "Of course, the file format is only one aspect"?

I also don't understand: "But if it does not harm, it does not good either, as far as promoting convergence is concerned." As Robin said, Apple pulled out a patent exclusion to try to derail the work. It's also being supported in Windows Mobile 6.5, which I personally see as pretty significant.

Anyway, thanks for the comments and discussion. If there is anything we can do to improve the spec, please don't hesitate to email us or just comment here.

Kind regards,
Marcos
(Editor of Widget's P&C spec)

Marcos: Oh good.

"One aspect"? I just meant that there are other parts of the Widgets effort, such as the APIs.

By "it does no good either" I mean that I think we have a rapidly lost opportunity for a common standard layer for packaging. All these groups need packaging, but it is not their focus, so we have five or six different specs doing the same thing.

At the very least, why is there a widgets: URI scheme? The pack: scheme is already an OASIS and ISO standard for accessing ZIP files and it has an internet draft.* Why not embrace and extend pack:, if needs be?

The ODF group at OASIS has its packaging draft out at the moment too. The OOXML packaging standard has quite a few layers for indirect addressing that would be complete overengineering for Widgets.

So the best that I hope for is that the different packaging specs are at least independently aligned on matters of common interest: there is a great commonality on the basic issues already (e.g using deflate.)

My expectation is that we will see more files that both X and Y (both ODF and OOXML, both Widgets and SCORM, etc.) as the path of least resistance for harmonization/convergence: common use of ZIP, common media components, but both XMLs. Which is why I think it would serve the public well if there are *at least* no incompatibilities, and preferably actual positive efforts at alignment.

But a common URI scheme (i.e. pack:) would be good.

*http://tools.ietf.org/id/draft-shur-pack-uri-scheme-05.txt

The pack:// uri scheme is not useful because it lacks http semantics (i.e., it does not respond like a HTTP server), which makes it kinda useless for things like XHR'ing to get a file in a package.

News Topics

Recommended for You

Got a Question?