Re: [widgets] Authorities will never have authority?

Hi Larry,

On Dec 27, 2009, at 00:22 , Larry Masinter wrote:
> In your message, you start to give a use case for how
> the "authority" field might be used, namely that
> the working group might have plans to introduce
> inter-widget communication, and to use the authority
> field, presumably in some way that would allow
> inter-widget references.

That is certainly something that's been considered yes.

> I want to point out there's a serious problem with
> IRIs and authority fields, and some pressure -- from
> browser vendors! -- to treat the "authority" field as
> a domain name in all cases, when translating from
> Unicode -- and turn an IRI with unicode authority
> into a URI by using punicode rather than percent
> encoded UTF8 in hex as with the rest of the IRI.

I don't represent a browser vendor so I can't speak for them. That being said I believe that the issues that you mention are raised largely based on the idea that these IRIs would be user-facing at some point? Within widgets, we don't envision that being the case. Note further that we can probably adapt to such changes (or am I missing something?).

> So the webapps working group's intent to reserve
> the authority field for use as identifying other
> widgets to enable inter-widget communication might
> have some problems, unless the intra-package
> authority is always required to be US-ASCII.

If there are good reasons to always require it to be US-ASCII (in this version or subsequent ones), we can certainly do so.

> But
> if you don't say what you're intending to use the
> authority field for, how can we review it?

IRIs are structured strings that can be decomposed into fields. We're marking one such field, which can be described (and therefore skipped) thanks to its syntax. We're reserving that field for future use. If we knew for certain what we intended to use it for, in sufficient detail, we wouldn't need to reserve it would we? :)

What we do know is that we do not need it at present, but that there have been several proposals to put it to work based on further investigation that needs to be undertaken. We could wait for these investigations to finish, but that would create a hiatus during which widget user agents would have to invent something to fill the many fields that expose URIs within the web stack (e.g. document.location, img.src, etc.), which in turn would create interoperability issues.

> I will point out that the WebApps working
> group charter
> 
>   http://www.w3.org/2008/webapps/charter/
> 
> only lasts until June 2010. So when you say
> that at some point in the future "the working
> group" intends to introduce inter-widget
> communication supported by the authority
> field, which working group are you presuming
> would do that, when? 

For obvious reasons I cannot speak on behalf of the membership or the W3C, but I would expect the WebApps WG to be rechartered rather than disbanded. If it is to be disbanded (or undergo massive change in scope) then I would hope that the participants would get advanced warning of that so that we can get our current work in order in time. Assuming it does go on working, I would expect the likes of interwidget communication and other such goodies to be on the new charter.

> As you are aware, I am sure, there are several
> other zip-based packaging systems in use:
> 
> http://broadcast.oreilly.com/2009/01/packaging-formats-of-famous-ap.html
> 
> Should each invent their own URI schemes for
> holding top-level of intra-package relative
> references? Is the applicability of "widget"
> and inter-package references restricted only
> to W3C widgets? Would you want it to be
> impossible to use the scheme to reference,
> say, a resource within a JAR file?

Widgets aren't a zip-based packaging system, they simply use Zip to package themselves up. The difference is important: the fact that Zip is used is just an implementation detail. Should all protocols that operate over IP use the same scheme? Probably not; and this is no different.

Widgets are an application format. The URI scheme that we've made for them reflects the way in which this application format was conceived (a finite set of localised resources being loaded in a web runtime). I wouldn't expect such a scheme to be useful to apply to zip archives or other packaging mechanisms.

> Perhaps some of those other systems have a
> different or similar mechanism? How can they
> evaluate "widget:" for reuse if you don't
> say how various parts of a widget URI will
> be interpreted?

The feedback we've received to date seems to indicate that they haven't had much trouble doing so. They read the widget family of specifications (at the very least the URI scheme and the Packaging and Configuration documents), have seen that we have clearly different use cases and therefore approaches, and decided that we don't need to converge. ISO/IEC JTC1/SC34/WG4 (the OOXML people) wrote about that recently[0], and ISO/IEC JTC1/SC29/WG11 (MPEG) is looking at widgets that would work in the exact same way but rely on a ISOFF packaging instead of Zip[1].

[0] http://www.w3.org/mid/546c6c1c0912282309j33354244p43c8b25e2cb983aa@mail.gmail.com
[1] http://www.chiariglione.org/mpeg/technologies/mpeg-u/mpu-widgets/index.htm

> Or are those other committees allowed to define
> a use for "authority" or "query" since the
> W3C WebApps working group merely reserved them
> for further use without any restrictions?

I'm not sure how we could at the same time reserve something and expect others to define it?

> Or do you want to rule out convergence of
> multiple zip-based packaging schemes in the
> future?

It would be great if we could converge all the schemes that provide ways of pointing into a Zip archive. But that's not the goal of Widget URIs, so I don't expect to take this convergence into account, no.

-- 
Robin Berjon - http://berjon.com/

Received on Monday, 11 January 2010 17:08:14 UTC