Mailing-List: contact repository-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: repository@apache.org
Message-ID: <3FB7C5F2.7030604@apache.org>
Date: Sun, 16 Nov 2003 19:46:10 +0100
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: repository@apache.org
Subject: Re: Use of '/' in ???-specifier's
References: <NBBBJGEAGJAKLIDBKJOPKEBBFGAB.noel@devtech.com>
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPKEBBFGAB.noel@devtech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Noel J. Bergman wrote:

>>maybe the [organization]/[product] notion is artificial.
>>What [organization]/[product] and [organization]/[product]/[version]
>>do is to establish a path to an logical artifact.
>>    
>>
>
>At any of it does is establish a path to a logical artifact.  Seems to me
>that there is limited utility to being able to parse the URI, and that the
>real key is having meta-data with which to assemble it.  But others don't
>seem to agree with that view.  They want to parse semantic information from
>the URI.
>
>  
>
>>we should not be focussing on the url as a spec - but instead
>>we should be focussing on the url as a [artifact-identifier]
>>and from that point on we should be using metadata to provide
>>us with the information about organization, product name,
>>available versions, etc.
>>    
>>
>
>So your feeling is that once you have a URI for the root component for a
>tool, you want meta-data suitable for your tool to indicate the location(s)
>of other content, such as license, dependents, etc.  Those location(s) can
>be specified either by a full URI, or after all of Tim's good work, by URI
>parts, which the specification tells us how to assemble.  The latter is how
>I have been viewing things so far.
>
>The meta-data could be in the form of a POM, a JNLP file, or some other
>format, and the tool would indicate what it is looking for as previously
>discussed.  I think that's where you're going, right?
>

In principal ... yes.

But I am making an assumption that a very simple named value pair 
metadata syntax could be assumed along with a meta mime type. References 
in that structure could be absolute or relative to the location of the 
metadata file.  Releative to the java world - that schema could be 
equivalent to the Properties format (i.e. "some-name = some-value").  
Given something like this - it becomes a lot simpler to seperate 
mechanics of access from logic of usage, while maintaining potential for 
cross-application interoperability (although that would require at least 
a very very small set of standard properties - e.g. language and 
application domain).

Cheers, Steve.


>>I'm not keen on being the odd-guy out
>>    
>>
>
>I don't think that you are.  There may be some undocumented assumptions
>going on, and this helps to clarify them.  For example, the above may help
>explain to Adam why I have been unconcerned about the ability to
>unambiguously parse a URL, whereas I do care about being able to assemble
>one.
>
>	--- Noel
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|