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