Re: [widget-uri] Widget URI ABNF definition comments

Dear Jere,

On Sep 15, 2009, at 12:49 , <Jere.Kapyaho@nokia.com> <Jere.Kapyaho@nokia.com 
 > wrote:
> I'm a sucker for all things ABNF. :-)

Well it's always good to have one of those around!

> /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?

Exactly. When we do define what the authority looks like, we may in  
fact want to use the iuser part. But in general since we don't know,  
the idea is that URI consumers can parse it, even if it simply means  
that they skip it.

> /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.

I *think* that this case is for relative references, e.g. http:/foo/ 
bar.svg or widget:license.html. On thinking about it, I'm guessing we  
should support those as well. In turn, this entails that the ABNF we  
use is wrong, or at the very least incomplete, which means that we  
should change it.

> 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.

So taking a different tack to defining the syntax, we could state that  
for a URI to be a valid widget URI, then it must match the IRI  
production in RFC 3987, with "scheme" being "widget". That pretty much  
makes us as safe as can be syntax-wise.

We then need a "Rule for converting the ipath-* bits to a file name  
field", and anything that cannot be converted is simply considered to  
resolve to nothing (the equivalent of a 404). This requires a bigger  
change than I'd hoped, but I think it's probably the right thing to do.

> /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. :-)

Hehehe. What I've gone for at this point is to make a blanket  
statement saying that every time it says URI, what it means is IRI.

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

Received on Thursday, 17 September 2009 11:22:40 UTC