W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

[widget-uri] Widget URI ABNF definition comments

From: <Jere.Kapyaho@nokia.com>
Date: Tue, 15 Sep 2009 12:49:23 +0200
To: <public-webapps@w3.org>
CC: <robin@berjon.com>
Message-ID: <C6D54BE3.81F3%jere.kapyaho@nokia.com>
Robin, all,

I had a look at the Widget URIs Working Draft of 08 Sept 2009, and a couple
of questions popped into mind, since I'm a sucker for all things ABNF. :-)

/1/ Is it the intent that the 'opaque authority' corresponds exactly to the
iauthority definition in the ABNF? If so, am I correct in assuming that it
doesn't matter at this point that there is no mention of the iuserinfo and
port components wrt. widget URIs, because the opaque authority intentionally
has no semantics?

/2/ Also, I'm trying to figure out what is the relationship between
zip-rel-path (as found in Widgets P&C) and ihier-part (as found in RFC 3897)
-- if we rely on RFC 3987 then I think these parts must agree. Based on the
current ABNF definition of the widget URI, it seems that the only matching
variant of ihier-part is

"//" iauthority ipath-abempty

since that is the only one with "//", although I'm not sure why it needs to
be so.

If we disregard iauthority (for reasons detailed above), the question then
becomes: is zip-rel-path compliant with ipath-abempty? Both of those
definitions are quite complicated, and I would be (pleasantly) surprised if
it turned out that they do match.

My concern here is that we should not say a widget URI is an RFC 3987
compliant IRI unless that definition is really valid, so I'm trying to make
the connections and tie any loose ends to be able to say that with
confidence.

/3/ Since we rely on RFC 3987, I guess the widget URI definition should
reuse components from IRI as much as possible. But in the end, it all boils
down to whether someone using a bona fide IRI validator (if those even
exist) would be able to get consistent results when feeding it with widget
URIs. And of course it becomes more interesting when widget URIs point to
files inside the widget package that have non-ASCII characters in their
names.

/4/ Finally, the IRI vs URI naming debate applies as ever. I agree it's
messy in that we are so accustomed to URIs, but really should be using IRIs,
and that not everyone is conditioned to mentally replace URI with IRI every
time. Maybe changing the document name to "Widgets 1.0: Widget Resource
Identifiers" would sidestep some of the problem. :-)

Best regards,
Jere
Received on Tuesday, 15 September 2009 10:50:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT