The URI proposals so far specify URIs which are
just as parseable as those currently in use by maven's
The only caveat is that they need to be parsed
from right to left, as the organisation  part of
product-specifier cannot be separated from the directory
part of access-specifier, without prior knowledge of
the repository structure.
E.g: if a repository has its root at:
And the organisation of a project is:
And the project name is:
needs to be parsed from right to left to determine that
the project is "commons-cli".
Without knowing that the repository has its root at:
the organisation cannot be determined.
Like maven's repository, which doesn't impose any
version naming convention, tools trying to parse
the URI need to make guesses as to which version
is older or newer.
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED]
> Noel wrote:
> > > You don't have to like the tool, I'm not trying to push the
> > I've never even seen the thing, and you are a priori assuming
> that I don't
> > like it?
> No Neol, I'm not that emoition, I meant it dispassionately and without
> inference, maybe it just read differently. That was more 'one'
> doesn't have
> to like it. [I know this list has (in the past) slipped into
> & codebase factions, and I was hoping not to encourage that.] So perhaps I
> should've writen ... "One doesn't have to like this
> tool/implementation, but
> the results are valuable at layer 1".
> > > It allows you to query what is there, query and capture "oldest
> > > [and do a delete/clean], and download newest, etc.
> > How does it know what OLDEST means? I see that Tim is trying
> to add some
> > more structure, so maybe he's thinking that we can restrict the
> URI space
> > that a restricted notion of version assures an automatable concept of
> > succession.
> Ruper parses all the attributes of the resources, including the
> version, and
> either do (pchar) string comparisons or (in versions case) structured
> comparisons. Much as there are a few different flavours of a versions they
> pretty much fall into a parsable pattern. Ruper (through Version) strictly
> parses the string in a number of different ways (known formats) until one
> Again, the most important aspect of parsing the URI is knowing what is
> separated from what, that this pchar is a version, this pchar is
> a type (or
> whatever). If values can by groked within that, great, if not, it is still
> > > Some find such a tool useful, I'd like to believe that apache users
> > (admins
> > > and external users) would find it useful.
> > I don't disagree. I simply said that if you view the
> repository solution
> > a layer of specifications, the lowest layer can be a syntax
> that does not
> > require semantics such as an automatable concept of succession. If we
> > that, we can add it either by a convention within the URI space, or by
> > means.
> We all agree to layers, but I am testing what are the minimum things we'll
> accept for layter one. I beleive that the repository needs to be 'tooling
> readable', hence the URI needs to be parse, the other aspects (can an
> attributed be fully groked) can come later.
> Again, I need to get to the wiki to put a proposal and pros/cons, I'll try
> next week.
> > Absolutely. But that may require something more than the URI
> schema. :-)
> But if it doesn't "have" to, should it? I'm trying to determine what we
> ought will accept at the lowest level. I think "clean up" is important, I
> like the other aspects. I agree that much should be done via
> metadata (e.g.
> dependencies) however writting potentially shared/conflicting files to a
> repository is a scary step, and I'd like to see how much we can do with
> atomic artefacts.
> > > I feel we have the potential to win big, and I'd like the ASF
> > > Repository to be a step forward towards these goals, not a step
> > I agree. But one layer at a time. :-)
> Yes, and we are doing layer one -- without metadata, we still need to
> determine our minimum expectations. If URI is this contentious/involved, I
> could see metadata as being a long drawn out process & one we
> don't agree on
> as a whole. Maybe this first layer is the hardest, but I'd like
> it to be the
> one giving the most rewards so we aren't all sitting waiting for metadata.