RE: Parsable URI (Re: [proposal] URI Syntax - v0.2)
The URI proposals so far specify URIs which are just as parseable as those currently in use by maven's repository [1]. The only caveat is that they need to be parsed from right to left, as the organisation [2] 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: http://www.apache.org/repository And the organisation of a project is: "org/apache" And the project name is: "commons-cli" The URI: http://www.apache.org/repository/org/apache/commons-cli 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: "http://www.apache.org/repository"; 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. -Tim [1] http://www.ibiblio.org/maven [2] http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax > 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 > implementation > > > > 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 > implementation > & 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 > resources" > > > [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 > so > > 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 > matches. > > 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 > as > > 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 > need > > that, we can add it either by a convention within the URI space, or by > other > > 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 > backward. > > > > 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. > > regards, > > Adam >
Parsable URI (Re: [proposal] URI Syntax - v0.2)
Noel wrote: > > You don't have to like the tool, I'm not trying to push the implementation > > 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 implementation & 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 resources" > > [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 so > 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 matches. 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 as > 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 need > that, we can add it either by a convention within the URI space, or by other > 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 backward. > > 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. regards, Adam
RE: [proposal] URI Syntax - v0.2
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > > > My input here is primarily based on writting Ruper > > > You don't have to like the tool, I'm not trying to push the > implementation > > I've never even seen the thing, and you are a priori assuming that I don't > like it? > > > It allows you to query what is there, query and capture "oldest > resources" > > [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 so > that a restricted notion of version assures an automatable concept of > succession. > The common build version specifier proposal does add structure to the version, but doesn't enable tools to determine if one version is older or newer than another. A tool could reasonably assume that version "1.0" < "2.0" but this is only valid for projects which follow numeric versions. For those projects which love codename versions (e.g, "chicago", "delta"), no assumptions can be made. -Tim
RE: [proposal] URI Syntax - v0.2
> My input here is primarily based on writting Ruper > You don't have to like the tool, I'm not trying to push the implementation I've never even seen the thing, and you are a priori assuming that I don't like it? > It allows you to query what is there, query and capture "oldest resources" > [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 so that a restricted notion of version assures an automatable concept of succession. > 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 as 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 need that, we can add it either by a convention within the URI space, or by other means. [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] > I'd like to say "go get me xerces from any repository it is in, > but get me the latest, but I only want release not nightly/snapshot" > That to me, is useful. Absolutely. But that may require something more than the URI schema. :-) > 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 backward. I agree. But one layer at a time. :-) --- Noel
RE: [proposal] URI Syntax - v0.2
> From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] > You could have the client tool be told the resource/URI by the user, > and do the download/verification, yes. That said, I don't think it buys > the user enough, they have to browse/locate & stash the URI in some local > config. I'd like to say "go get me xerces from any repository it is in, > but get me the latest, but I only want release not nightly/snapshot" (e.g. > http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. > > I don't mind being alone in my views, but I ask again -- if we > don't set the > bar higher than a one-way URI for download, why write a spec at > all? 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 backward. > I believe this is possible using the current proposals. If tools follow these when deploying artifacts, a user can can say "go get me the latest formal xerces build". That said, some configuration will always be required, whether it be like maven's project.xml dependency resolution, or some other scheme. The proposals aim to avoid users explicitly using URIs. Users should be able to supply a set of criteria and the tools be responsible for constructing the URI. -Tim
Re: [proposal] URI Syntax - v0.2
Noel wrote: > Adam, and how is said tool going to start in the first place? Without > meta-data, there is a limit to what the tool can do. Basically, it would > have to operate relative to the URL provided to it. My input here is primarily based on writting Ruper (http://www.krysalis.org/ruper), a tool that attempts exactly what I said. It is given links to repositories (local or remote), it read the repositories and allows queries into that repository based on attributes of the resources. It does this by parsing the URLs. You don't have to like the tool, I'm not trying to push the implementation, I'm just giving you experiences from that tool. It allows you to query what is there, query and capture "oldest resources" [and do a delete/clean], and download newest, etc. 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 care whose implementation gets used, I feel that these capabilities are so powerful that they ought consist of a minimum bar for apache. Sure, it isn't going to be a 100% generic tool for all cases, but apache is doing this for apache. Let the tools lead and the users (our own committers) can chose to follow. Once, along came a browser and sooner or later folks were converting their documents to HTML 'cos the benefits outweighed the resistence to change. I'm saying that we can't enforce things, but if we make the benefits sufficiently worthwhile & transition easy folks then most folks will follow. Again, this tool works today on over 95% of the contents of the Maven repository without any spec. We could achieve this. A nice simple IDE plugin can update a project and download files with or w/o user intervention, e.g. http://www.krysalis.org/ruper/eclipse/index.html. > Tim's URI schema supports your operations when combined with with a semantic > layer, which can be implied or meta-data based. Aren't you saying that metadata can allow a remote tool to instrospect? Yes, I agree, this has nothing to do with an unparsable URI scheme. The URI scheme is generally fine, but if we aren't addressing metadata (almost impossible) why set back tools that mine metadta from URIs? It works today, why would we force a step backwards? [I sometimes feel the acadaemics of the URI Scheme Specifiecation are outweighing the practicalities of an implementation. I beleive in writting a specification first, but specifications get revised based upon real world experience. Tools are that experience.] > > For me, the strongest argument for tooling (other purely than saving > admins > > effort) is download + verify (MD5/whatever). > > That does not require the kind of semantic your earlier operations require. > The verification content can be relative to the URI provided to the tool. True, my bad, I go carried away with my argument, the tool I am familiar with, and my own dislike of stale software links. You could have the client tool be told the resource/URI by the user, and do the download/verification, yes. That said, I don't think it buys the user enough, they have to browse/locate & stash the URI in some local config. I'd like to say "go get me xerces from any repository it is in, but get me the latest, but I only want release not nightly/snapshot" (e.g. http://www.krysalis.org/ruper/ant/reposync.htm). That to me, is useful. I don't mind being alone in my views, but I ask again -- if we don't set the bar higher than a one-way URI for download, why write a spec at all? 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 backward. regards Adam
RE: [proposal] URI Syntax - v0.2
> > However, I don't think this is unreasonable. There is no requirement > > that tools be able to parse URIs to extract meta-data. > There is a requirement that repositories "work" (at some minimum level) > without metadata, especially since we aren't specifying metadata. > Without a parsable URI (or parsable URL) how do tools read a repository > to do things like "clean oldest nightly/snapshot, but leave all releases", > "download latest release" or even the basics "determine/display contents", > "show basic contents" (irrespective of version/type). Adam, and how is said tool going to start in the first place? Without meta-data, there is a limit to what the tool can do. Basically, it would have to operate relative to the URL provided to it. As for the particular examples you gave, those carry semantic meaning that would require more specification that is contained in the URI syntax. Although those would be desirable, I don't know that we want to including that kind of semantic specification in the URI. > If we are proposing a standard, there has to be a valid purpose for it > -- and having a standard that isn't structured for computer processing > seems setting the bar pointlessly low. Tim's URI schema supports your operations when combined with with a semantic layer, which can be implied or meta-data based. > For me, the strongest argument for tooling (other purely than saving admins > effort) is download + verify (MD5/whatever). That does not require the kind of semantic your earlier operations require. The verification content can be relative to the URI provided to the tool. --- Noel
Re: [proposal] URI Syntax - v0.2
> > >However, I don't think this is unreasonable. There is no requirement > > >that tools be able to parse URIs to extract meta-data. Say who? There is a requirement that repositories "work" (at some minimum level) without metadata, especially since we aren't specifying metadata. Without a parsable URI (or parsable URL) how do tools read a repository to do things like "clean oldest nightly/snapshot, but leave all releases", "download latest release" or even the basics "determine/display contents", "show basic contents" (irrespective of version/type). If we are shooting for humans, not tools, why bother changing what we have? Humans can grok it all, we don't need any "standard". If we are proposing a standard, there has to be a valid purpose for it -- and having a standard that isn't structured for computer processing seems setting the bar pointlessly low. For me, the strongest argument for tooling (other purely than saving admins effort) is download + verify (MD5/whatever). A human is far more likely NOT to do it, they'll right click in their browser, save and use. I think we ought have a structured repository so we can write administration tools, but also timer save "download" plugins that do the requisite verifications and keep our users secure. Again, a specification that limits/breaks tooling is wasting of huge benefit. regards, Adam
Re: [proposal] URI Syntax - v0.2
Tim Anderson wrote: ink easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. I think I see, A tool only needs to be able to generate a URL given the org, project, version, and artifact name. No need to be able to parse a given URL back into it parts. I think I can live with that. -Tim smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
> From: Nick Chalko [mailto:[EMAIL PROTECTED] > > Tim Anderson wrote: > > >>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 > > > > > I think easing the job for tools is a good goal. > > We must support both Humans and Tools. > I would favor Humans. But both humans and tools will have problems > when some orginzation decides its project name is Beta or nightly, etc > > I think we should consider not allowing / in many of the parts. > > R, > Nick For tools, I think the main objective should be coming up with a set of rules which enable them to unambigously locate an artifact given a set of inputs. I believe this is possible with the two proposals so far, at least for java artifacts. -Tim
Re: [proposal] URI Syntax - v0.2
Tim Anderson wrote: 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 I think easing the job for tools is a good goal. We must support both Humans and Tools. I would favor Humans. But both humans and tools will have problems when some orginzation decides its project name is Beta or nightly, etc I think we should consider not allowing / in many of the parts. R, Nick smime.p7s Description: S/MIME Cryptographic Signature
RE: [proposal] URI Syntax - v0.2
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) > > > > 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 | "_" | "-" | "!" | "~" | "@" | "&" > >
Tooling (was Version Specifier in Re: [proposal] URI Syntax - v0.2)
> Its great idea to make Artifact Specifier to be opaque to give way to > different languages, but I am not sure about the Version Specifier. Version > Specifier can be considered as language independent and allowing different > best practices in there would make the repository unordered and could > confuse the users. I know of opinions on both sides. Some say we can't dictate, so best practices are the best we can expect & even they'll be loose. Others say, we can't achieve conformity unless we try -- and that tools can't process totally unstructured opaque data. I think the questions become (building upon each other): 1) Ought the URI be uniquely (unambiguously) parsable [i.e. things such as your '-' not '/' proposal.] 2) Ought the URI be considered 'metadata' itself & structured? 3) Is the goal for the repository to be "tools processable" [even without metadata]? I'll work something up in the Wiki TODOs section and transfer any pros/cons there. --- One last comment on "tools-based" verses "human-based". We are discussing "version in filename so it's version is identifiable once download from the repository". It occurred to me that we are likely assuming a dumb client (a human w/ browser perhaps) in that thought. Nothing is to stop tools downloading an unversioned filename and adding -[version] to the end as it writes it to disk. Since we can likely assume that many humans have bad habits of not doing verification checks of the contents of repositories that they download with a browser, ought we actually weight our cogitations towards tooling that can browse/select/download/verify. Note: I'm not talking implementation, nor any tool, and I'm definitely not saying disallow the human user use case, I'm just saying focus on tooling. IMHO tooling (built upon certain levels of repository consistency) make the repository@ venture more than just a re-organization of file systems, and allow us to scale this and save a lot of wasted human effort. It seems a critical goal to me. Thoughts? regards Adam
Re: [proposal] URI Syntax - v0.2
Digesting each section slowly, Its great idea to make Artifact Specifier to be opaque to give way to different languages, but I am not sure about the Version Specifier. Version Specifier can be considered as language independent and allowing different best practices in there would make the repository unordered and could confuse the users. "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/xorg/xyz/release/1.2 http://repo.apache.org/yorg/abc/v0.9-beta/abc.. thoughts ? 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]&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) 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) 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". 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-logging-1.1.ja r http://repo.apache.org/apache/httpd/
Re: [proposal] URI Syntax - v0.2
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]&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) 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) 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". 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-logging-1.1.ja r http://repo.apa
[proposal] URI Syntax - v0.2
This version replaces v1.0: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&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) 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) 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". 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-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 Rationale = Of the URI components: . and are common accross all languages and deployments. . is subject to language or deployment best practices . 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 "/" produc
