> 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

Reply via email to