I thought it would be appropriate for me to explain my resistance to
using URI with a list schemes in place or URL. This is best served
by example. Let's look at the source element, which has an attribute
url. I think for starters everybody can agree that changing the name
of the url attribute uri is a bad idea, as it would invalidate every
existing RSS feed that uses the source element. But I don't expect
any argument there. The argument is whether we should define that
url attribute to be a URI with a list of acceptable schemes. For
argument sake, let's say we allow http and https. Months go by and
the community at large begins to adopt use of the feed scheme (ex.
feed://feeds.feedburner.com/TheRSSBlog). Do we then modify the RSS
specification to include this new scheme? Surely we would have to.
On the other hand, if we said that the url attribute had to the a
network addressable URI (or URL), then we don't have to modify the
spec when new URIs come into popularity. This same argument applies
to guid, comments and link elements. If we want to respect the
wishes not to use the term URL in specifications, then I propose we
adopt the following definitions.
-source/@url is the network addressable URI
-link is the URI of a Webpage
-image/@url is the network addressable URI
-image/@link is the URI of a Webpage
-guid (with isPermaLink='true') is the URI of a Webpage
-comments is the URI of a Webpage
We can then have a section on URIs that explains what a URI is
(points to the definition) and what is meant by Webpage and network
addressable. Or we can just keep using URL. I hope this helps to
clarify the argument.