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