> maybe the [organization]/[product] notion is artificial. > What [organization]/[product] and [organization]/[product]/[version] > do is to establish a path to an logical artifact.
At any of it does is establish a path to a logical artifact. Seems to me that there is limited utility to being able to parse the URI, and that the real key is having meta-data with which to assemble it. But others don't seem to agree with that view. They want to parse semantic information from the URI. > we should not be focussing on the url as a spec - but instead > we should be focussing on the url as a [artifact-identifier] > and from that point on we should be using metadata to provide > us with the information about organization, product name, > available versions, etc. So your feeling is that once you have a URI for the root component for a tool, you want meta-data suitable for your tool to indicate the location(s) of other content, such as license, dependents, etc. Those location(s) can be specified either by a full URI, or after all of Tim's good work, by URI parts, which the specification tells us how to assemble. The latter is how I have been viewing things so far. The meta-data could be in the form of a POM, a JNLP file, or some other format, and the tool would indicate what it is looking for as previously discussed. I think that's where you're going, right? > I'm not keen on being the odd-guy out I don't think that you are. There may be some undocumented assumptions going on, and this helps to clarify them. For example, the above may help explain to Adam why I have been unconcerned about the ability to unambiguously parse a URL, whereas I do care about being able to assemble one. --- Noel