Having said that, I think there is one point I disagree with - more in the
wording than the meaning. point 12 (I believe) said that a URV and a URL
never meet each other. I disagree, in a typical client application the URV
is a property of a URL. I.e. having performed
resolve(URN,URV) -> {URL1,URL2,URL3}
I'm going to hang on to one of the URL's (the closest?) and tack the URV and
URN into a data structure with it. This tells me the properties of my URL,
and allows me to make decisions about how to display it etc. I could even
see these getting written down somewhere e.g.
Where can I get a copy of URN:ISBN::1234567:::
Its in the library, try URL=gopher:1/xxx/yyy URV=Content-Type: postscript
i.e. the URV is not something you need to know to retrieve the URL, but its
a valid peice of information to pass around with it.
I believe that the concept of URV is equivalent to URM as presented last
meeting, Lets pick one of the terms and stick with it - personally i prefer
URV but dont really care.
I'd like to add one more point to be consensed on, if their is consensus.
"URC is defined as any combination of one or more URL's or URN's with
optionally URV's. We havent defined what it looks like yet, but this is what
it is."
The reason I suggest this is that Dirk mentioned that a URV might have two
dimensions "location and format" - location is definately not one of the
dimensions of a URV, its part of the URL. A URC might have two dimensions -
location and format - if its parts where a URL and a URV.
- Mitra