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
this makes more sense as org / project http://repo.apache.org/org-apache/commons-logging
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]&ms gNo=308
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
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".
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
http://repo.apache.org/apache/common-logging/1.1/jars/commons-logging-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
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.
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.)