Dear Jere,
On Sep 15, 2009, at 12:49 , <[email protected]> <[email protected]
> 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/
