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

| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
|                |
|                               |

Reply via email to