I changed organisation to name-segments to support structures
using reverse-FQDNs e.g:
  http://repo.apache.org/org/apache
  http://repo.apache.org/org/tigris
  http://repo.apache.org/com/sun

while maintaining support for single segment organisation names e.g:
  http://repo.apache.org/oracle

See the comments regarding groupId in the original proposal for
background:

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&ms
gNo=308

>From a tool perspective, it can unambiguously locate a project
when given inputs of:
  "org.apache"  -> must replace "." with "/" before performing lookup
  "org/apache"
  "oracle"

The implication of this is that generic tools can't parse the URI
and determine what is part of the product-specifier and what is
part of the version-specifier.

However, I don't think this is unreasonable. There is no requirement
that tools be able to parse URIs to extract meta-data.

-Tim


> From: Anou Manavalan [mailto:[EMAIL PROTECTED]
>
>
> Tim,
>
> This is very nicely laid out.
>
> I have one little suggestion,
> In the Product Specifier,  can the organization be made as just
> name-segment ? This avoids the confusion of “/” separator that
> separates the
> main things like the orgainization ”/” project with “/” separating the
> organisation itself.
>
> I mean, replace “.” By “-“ instead of “/”  - since “/” is used as
> the main
> separation.
>
> Instead of this, where it is hard to say where the org ends and where the
> project starts, you sure can differentiate it, but
> http://repo.apache.org/org/apache/commons-logging
>
> this makes more sense as org / project
> http://repo.apache.org/org-apache/commons-logging
>
>
> regards,
> -Anou
>
> >From: "Tim Anderson" <[EMAIL PROTECTED]>
> >Reply-To: <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [proposal] URI Syntax -  v0.2
> >Date: Fri, 14 Nov 2003 16:39:06 +1100
> >
> >This version replaces v1.0:
> >http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
> ache.org&ms
> >gNo=308
> >
> >
> >Overview
> >========
> >
> >The key aims of this proposal are:
> >. language and artifact neutrality.
> >   It should be possible to support multiple languages and
> >   their artifacts, not just java.
> >
> >. it should be possible for users to easily navigate
> >   the repository and locate artifacts, including
> >   jars and release distributions.
> >   Compare this with the existing approach of separating
> >   release distributions (http://www.apache.org/dist/) and jars
> >   (http://www.ibiblio.org/maven).
> >
> >. it should be possible for tools to construct a URI
> >   to locate an artifact using a set of known criteria
> >
> >Artifacts
> >---------
> >
> >All files in the repository are artifacts. There is no distinction
> >between artifacts and meta-data. Any relationships between artifacts
> >is determined by supporting tools.
> >
> >
> >Repository URI Components
> >=========================
> >
> >An absolute repository URI is written as follows:
> >
> >   repository-uri = access-specifier "/" product-specifier "/"
> >                    version-specifier "/" artifact-specifier
> >
> >
> >Access specifier
> >----------------
> >
> >The access specifier determines the scheme, authority, and optional
> >repository directory prefix. There is currently no requirement for
> >ftp, scp or file based access - only http is supported:
> >
> >   access-specifier = http-access-specifier
> >   http-access-specifier = "http://"; authority "/" [directory "/"]
> >   directory = path_segments
> >
> >   (authority and path_segments are per
> >http://www.ietf.org/rfc/rfc2396.txt)
> >
> ><directory> is used when the repository cannot be located at
> >the root of an absolute URI.
> >
> >URI examples:
> >   http://repo.apache.org/
> >   http://repo.apache.org/pub/repository
> >
> >
> >Product specifier
> >-----------------
> >
> >The product specifier specifies the organisation and project:
> >
> >   product-specifier = organisation "/" project
> >   organisation = name-segments
> >   project = name-segment
> >   name-segments = name-segment *( "/" name_segment)
> >   name-segment = nchar+
> >   nchar = alphanum | escaped | "_" | "-" | "!" | "~" | "@" | "&"
> >
> >   (alphanum and escaped are per http://www.ietf.org/rfc/rfc2396.txt)
> >
> ><organisation> is the organisation name. It is arbitrary,
> >but should be globally unique. It could be the domain name,
> >or reverse domain name, with "." replaced by "/", e.g:
> >   "sun/com", "org/apache"
> >or simply the name of the organisation, e.g "oracle".
> >
> ><project> is the project name. It is unique within an organisation.
> >E.g, "ldap", "jndi", "maven", "commons-logging".
> >
> >URI examples:
> >   http://repo.apache.org/org/apache/commons-logging
> >   http://repo.apache.org/sun/jndi
> >
> >
> >Version specifier
> >-----------------
> >
> >The version specifier specifies the version of the project:
> >
> >    version-specifier = name-segments
> >
> >For the purposes of this proposal, version-specifier is opaque -
> >its format is determined by language and deployment best practices.
> >
> >Some possible examples include:
> >  "1.0", "v0.9-beta", "nightly/20031113", "latest", "release/1.5.4"
> >
> >URI examples:
> >   http://repo.apache.org/apache/commons-logging/1.0
> >   http://repo.apache.org/apache/commons-logging/1.1
> >   http://repo.apache.org/apache/commons-logging/latest
> >   http://repo.apache.org/apache/ant/release/1.5.4
> >   http://repo.apache.org/apache/ant/nightly/20031113
> >   http://repo.apache.org/apache/commons-cli/nightly/1.0/20031113
> >   http://repo.apache.org/apache/commons-cli/nightly/2.0/20031113
> >
> >
> >Artifact specifier
> >------------------
> >
> >The artifact specifier uniquely identifies an artifact within a
> >project version:
> >   artifact-specifier = name-segments
> >
> >For the purposes of this proposal, artifact-specifier is opaque -
> >its format is determined by language and deployment best practices.
> >
> >Some possible examples include:
> >  jars/commons-logging-1.1.jar
> >  binaries/linux/httpd-2.0.40-i686-pc-linux-gnu-rh73.tar.gz
> >
> >URI examples:
> >
> >http://repo.apache.org/apache/common-logging/1.1/jars/commons-log
> ging-1.1.ja
> >r
> >
> http://repo.apache.org/apache/httpd/2.0.48/docs/httpd-docs-2.0.48.en.zip
> >   http://repo.apache.org/apache/ant/1.5.4/KEYS
> >
> >
> >Rationale
> >=========
> >
> >Of the URI components:
> >. <access-specifier> and <product-specifier> are common accross
> >   all languages and deployments.
> >. <version-specifier> is subject to language or deployment
> >   best practices
> >. <artifact-specifier> is subject to language, deployment, artifact, or
> >   project best practices
> >
> >It is envisioned that there will be different repository deployment
> >and query tools developed for each language. A generic tool cannot
> >be written without providing supporting meta-data, which is outside
> >the scope of this proposal.
> >
> >Projects should be able to deploy arbitrary artifacts to the
> >repository, whether they be for end-users, or meta-data (e.g, maven's
> >project.xml). Tools should ignore any artifact they don't understand.
> >
> >To ensure interoperability between language-based tools, best-practice
> >guidelines need to be drawn up for each supported language and deployment
> >scenario.
> >
> >
> >Appendix
> >========
> >
> >Changes from v0.1
> >-----------------
> >
> >. repository-uri changed from:
> >     access-specifier "/" product-specifier "/" artifact-specifier
> >   to:
> >     access-specifier "/" product-specifier "/" version-specifier "/"
> >     artifact-specifier
> >
> >. product-specifier changed from:
> >     organisation "/" project "/" version
> >   to:
> >     organisation "/" project
> >
> >. organisation changed from:
> >     *pchar
> >   to:
> >     name_segments
> >
> >. project changed from:
> >     *pchar
> >   to:
> >     name_segment
> >
> >. version renamed to version-specifier, and is now opaque
> >
> >. artifact-specifier is now opaque
> >
> >
>
> _________________________________________________________________
> Frustrated with dial-up? Get high-speed for as low as $26.95.
> https://broadband.msn.com (Prices may vary by service area.)
>
>


Reply via email to