You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/11/25 18:58:49 UTC
Lookup string format
> >we had already been over the best way to format
> > the lookup string back in august
> On formatting, the concensus as I seem to remember was :
> <domain> ":" <key>
I'm slowly digesting the recent volume of discussions, but I just to toss in
an idea on this specific issue.
(1) There is the existing property convention, using the
standard java qualified name convention, e.g.,
org.apache.avalon.<local-name>
(2) Alternatively, there is RFC 2141, which appears to be
the direction you're indicating.
(http://www.ietf.org/rfc/rfc2141.txt)
As I understand it, Avalon has already gone over the choice between the
existing "Java" convention and a <domain> ":" <key> convention, and Stephen
indicates that he believes that the latter was chosen. Fine.
However, if Avalon is going to adopt a <domain> ":" <key> notion, then I
suggest that Avalon vote to adopt RFC 2141, and incorporate it by reference.
Incorporating RFC 2141 will save you from having to go through all of the
arguments already dealt with during the production of the RFC, and provides
more detailed and specific information necessary for users and implementors.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>Applying RFC 2141 is fine from my point of view.
>Wouldn't it be fine to have "avalon:" as the root? Like this:
>
>avalon:home.work
>avalon:merlin:something-special.whatever
>avalon:phoenix:something-solid.xxx
I would suggest that an RFC 2141 utility class is going to want to take a
URN, validate it, and make available the NID and NSS components. At that
point you are probably not going to want to have to do any further parsing
on either part. Therefore, you should stick with the NSS being the actual
keys you want, and the NID providing the domain.
This would mean:
urn:avalon:home.work
urn:avalon-merlin:something-special.whatever
urn:avalon-phoenix:something-solid.xxx
The difference being that ':' is not valid within an NID. It always
separates the NID from the NSS.
I do have a linguistic objection to the third example, by the way.
Something "solid" implies an implementation of an abstract item. In that
case, it should be looked up using the abstract item's key, so that it is
portable across all implementing containers. It is a linguistic nitpick,
perhaps, but I did want to point out the implication.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lookup string format
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Noel J. Bergman wrote:
>>
>>
>>>However, if Avalon is going to adopt a <domain> ":" <key>
>>>
>>>
>>notion, then I
>>
>>
>>>suggest that Avalon vote to adopt RFC 2141, and incorporate
>>>
>>>
>>it by reference.
>>
>>
>>>Incorporating RFC 2141 will save you from having to go
>>>
>>>
>>through all of the
>>
>>
>>>arguments already dealt with during the production of the
>>>
>>>
>>RFC, and provides
>>
>>
>>>more detailed and specific information necessary for users
>>>
>>>
>>and implementers.
>>
>>
>>Applying RFC 2141 is fine from my point of view. As such I need to
>>update the examples I provided earlier to reflect marlin and phoenix
>>as sub domains of the Avalon domain.
>>
>>
>
>Wouldn't it be fine to have "avalon:" as the root? Like this:
>
>avalon:home.work
>avalon:merlin:something-special.whatever
>avalon:phoenix:something-solid.xxx
>
>Why make the string longer than it needs to be?
>
I would tend to agree - after reading through RFC 2141 my initial
reaction was to cosider the domain compoent as "apache:avalon:...",
however, it is also valid to say that we are dealing with things that
are relative to the Context interface which is implicitly "avalon" as
root. As such your suggestion is completely valid.
Cheers, Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Noel J. Bergman wrote:
> >
> >However, if Avalon is going to adopt a <domain> ":" <key>
> notion, then I
> >suggest that Avalon vote to adopt RFC 2141, and incorporate
> it by reference.
> >Incorporating RFC 2141 will save you from having to go
> through all of the
> >arguments already dealt with during the production of the
> RFC, and provides
> >more detailed and specific information necessary for users
> and implementers.
> >
>
> Applying RFC 2141 is fine from my point of view. As such I need to
> update the examples I provided earlier to reflect marlin and phoenix
> as sub domains of the Avalon domain.
Wouldn't it be fine to have "avalon:" as the root? Like this:
avalon:home.work
avalon:merlin:something-special.whatever
avalon:phoenix:something-solid.xxx
Why make the string longer than it needs to be?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lookup string format
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>> apache-avalon-merlin:
>> avalon-merlin:
>> merlin:
>>
>>
>
>Any of the above patterns is fine with me. I imagine a two-stage registry
>where the NID is mapped to an NID-specific registry, which then maps the NSS
>to the identified object.
>
That's my asumption as well.
>Two stages are used because the second stage is
>permitted to interpret the NSS however it wants.
>
Yep.
>The NSS is not strictly a
>lookup key.
>
>Which actually lends strength to my earlier argument that
>urn:avalon:phoenix-blah is a bad thing to do. It requires the Avalon
>namespace to interpret the NSS on behalf of Phoenix. So that pretty much
>settles the proper usage pattern in my mind.
>
>Agreed?
>
Yep.
Cheers, Steve.
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
> apache-avalon-merlin:
> avalon-merlin:
> merlin:
Any of the above patterns is fine with me. I imagine a two-stage registry
where the NID is mapped to an NID-specific registry, which then maps the NSS
to the identified object. Two stages are used because the second stage is
permitted to interpret the NSS however it wants. The NSS is not strictly a
lookup key.
Which actually lends strength to my earlier argument that
urn:avalon:phoenix-blah is a bad thing to do. It requires the Avalon
namespace to interpret the NSS on behalf of Phoenix. So that pretty much
settles the proper usage pattern in my mind.
Agreed?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lookup string format
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Applying RFC 2141 is fine from my point of view. As such I need to
>>update the examples I provided earlier to reflect marlin and phoenix
>>as subdomains of the avalon domain.
>>
>>
>
>Is that what you want to do? There is no sub-domain notion within RFC 2141.
>
>The format of a URN is "urn:" <NID> ":" <NSS>. NID is Namespace IDentifier,
>and NSS is Namspace Specific String. One example might be:
>
> urn:avalon:home.work
>
>where "urn:" is required, avalon is the NID and home.work is the NSS. In
>all of your examples, the NID was apache, and everything else was the NSS.
>
>
>
>>update merlin specific keys to be RFC 2141 based on
>>a *apache:avalon:merlin* domain
>>
>>
>
>If "domain" is supposed to be NID, that would not be valid. The ':'
>character is not valid within an NID, and is valid within the NSS. So your
>string would be interpreted as having an NID of apache, with avalon:merlin:
>being part of the NSS, which is probably not what you're going to want
>internally when you process the NSS. Alternatively, you could use
>apache-avalon-merlin as an NID.
>
>
Yep - I was looking at the excluded charcter list - not the actual
included list.
Valid options for the NID (Namespace Identifier) for something like
Merlin would seem to include:
apache-avalon-merlin: (using hyphen because "." and ":" are not
allowed)
or
avalon-merlin:
or
merlin:
Given that there isn't a DNS like domain name equivalence here - I'm now
thinking it is easiest to run with:
avalon: + the avalon standard specification strings
phoenix: + the phoneix standard specification strings
merlin: + the merlin standard specification strings
fortress: + the fortress standard specification strings
See how easy it is for to change my mind!
;-)
Cheers, Steve.
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > Applying RFC 2141 is fine from my point of view. As such I need to
> > update the examples I provided earlier to reflect marlin and phoenix
> > as subdomains of the avalon domain.
>
> Is that what you want to do? There is no sub-domain notion
> within RFC 2141.
>
> The format of a URN is "urn:" <NID> ":" <NSS>. NID is
> Namespace IDentifier,
> and NSS is Namspace Specific String. One example might be:
>
> urn:avalon:home.work
>
> where "urn:" is required, avalon is the NID and home.work is
> the NSS. In
> all of your examples, the NID was apache, and everything else
> was the NSS.
>
> > update merlin specific keys to be RFC 2141 based on
> > a *apache:avalon:merlin* domain
>
> If "domain" is supposed to be NID, that would not be valid. The ':'
> character is not valid within an NID, and is valid within the
> NSS. So your
> string would be interpreted as having an NID of apache, with
> avalon:merlin:
> being part of the NSS, which is probably not what you're going to want
> internally when you process the NSS. Alternatively, you could use
> apache-avalon-merlin as an NID.
I think it is much simpler to do this:
urn:avalon:home.work
urn:merlin:something.special
urn:phoenix:something.specific
ALthough it is even simpler to drop the "urn:" portion as well ;P
I favor simplicity of the string we need to type or bind.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Applying RFC 2141 is fine from my point of view. As such I need to
> update the examples I provided earlier to reflect marlin and phoenix
> as subdomains of the avalon domain.
Is that what you want to do? There is no sub-domain notion within RFC 2141.
The format of a URN is "urn:" <NID> ":" <NSS>. NID is Namespace IDentifier,
and NSS is Namspace Specific String. One example might be:
urn:avalon:home.work
where "urn:" is required, avalon is the NID and home.work is the NSS. In
all of your examples, the NID was apache, and everything else was the NSS.
> update merlin specific keys to be RFC 2141 based on
> a *apache:avalon:merlin* domain
If "domain" is supposed to be NID, that would not be valid. The ':'
character is not valid within an NID, and is valid within the NSS. So your
string would be interpreted as having an NID of apache, with avalon:merlin:
being part of the NSS, which is probably not what you're going to want
internally when you process the NSS. Alternatively, you could use
apache-avalon-merlin as an NID.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lookup string format
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>we had already been over the best way to format
>>>the lookup string back in august
>>>
>>On formatting, the concensus as I seem to remember was :
>> <domain> ":" <key>
>>
>
>I'm slowly digesting the recent volume of discussions, but I just to toss in
>an idea on this specific issue.
>
> (1) There is the existing property convention, using the
> standard java qualified name convention, e.g.,
> org.apache.avalon.<local-name>
>
> (2) Alternatively, there is RFC 2141, which appears to be
> the direction you're indicating.
> (http://www.ietf.org/rfc/rfc2141.txt)
>
>As I understand it, Avalon has already gone over the choice between the
>existing "Java" convention and a <domain> ":" <key> convention, and Stephen
>indicates that he believes that the latter was chosen. Fine.
>
>However, if Avalon is going to adopt a <domain> ":" <key> notion, then I
>suggest that Avalon vote to adopt RFC 2141, and incorporate it by reference.
>Incorporating RFC 2141 will save you from having to go through all of the
>arguments already dealt with during the production of the RFC, and provides
>more detailed and specific information necessary for users and implementors.
>
Applying RFC 2141 is fine from my point of view. As such I need to
update the examples I provided earlier to reflect marlin and phoenix
as subdomains of the avalon domain.
For example:
apache:avalon:home.work <----- the working directory
apache:avalon:merlin:something-special.whetever <-- changed to
reflect merlin as a sub-domain of avalon and avalon as a sub-domain
of apache
apache:avalon:phoenix:something-solid.xxx <-- changed to reflect
phoenix as a sub-domain of avalon and avalon as a sub-domain of
apache
If there's no drama on this, I'll go ahead and update merlin specific
keys to be RFC 2141 based on a *apache:avalon:merlin* domain.
Cheers, Steve.
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by "Noel J. Bergman" <no...@devtech.com>.
> sounds good, +1.
> some notes on implications:
> - "Further, the Namespace Identifier is case insensitive"
Correct. The "urn:" prefix and the NID are case insensitive. It is up to
the context specified by the NID to determine if case is sensitive.
> - allowed in the namespace identifier are alphanumerics and the hyphen,
> not dots, so "avalon.phoenix:blah" is not allowed but
> "avalon:phoenix:blah" or "avalon:phoenix.blah" or "avalon-phoenix:blah"
Correct. The resulting breakdowns from your examples are:
NID NSS
avalon phoenix:blah
avalon phoenix.blah
avalon-phoenix blah
I consider the third example would be the best pattern for a Phoenix
specific identifier. The avalon namespace should not know about container
specific keys.
> anyone know of a URNUtils class or something like that?
Check Apache SOAP/Axis for an implementation. SOAP uses RFC 2141.
By the way, the "urn:" prefix, at a cost of four characters (a) provides a
quick validation for the parser, and (b) informs the reader that the
identifier follows RFC 2141. And it is required by the RFC.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lookup string format
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 18:58, Noel J. Bergman wrote:
> > >we had already been over the best way to format
> > > the lookup string back in august
> > On formatting, the concensus as I seem to remember was :
> > <domain> ":" <key>
>
> I'm slowly digesting the recent volume of discussions, but I just to toss in
> an idea on this specific issue.
>
> (1) There is the existing property convention, using the
> standard java qualified name convention, e.g.,
> org.apache.avalon.<local-name>
>
> (2) Alternatively, there is RFC 2141, which appears to be
> the direction you're indicating.
> (http://www.ietf.org/rfc/rfc2141.txt)
>
> As I understand it, Avalon has already gone over the choice between the
> existing "Java" convention and a <domain> ":" <key> convention, and Stephen
> indicates that he believes that the latter was chosen. Fine.
>
> However, if Avalon is going to adopt a <domain> ":" <key> notion, then I
> suggest that Avalon vote to adopt RFC 2141, and incorporate it by reference.
> Incorporating RFC 2141 will save you from having to go through all of the
> arguments already dealt with during the production of the RFC, and provides
> more detailed and specific information necessary for users and implementors.
sounds good, +1.
some notes on implications:
- "Further, the Namespace
Identifier is case insensitive"
(the rest is not, by default)
IOW "Avalon:blah" should be the same as "avalon:blah" but different from
"avalon:Blah"
- allowed in the namespace identifier are alphanumerics and the hyphen,
not dots, so "avalon.phoenix:blah" is not allowed but
"avalon:phoenix:blah" or "avalon:phoenix.blah" or "avalon-phoenix:blah"
is.
anyone know of a URNUtils class or something like that? Would it be
worth having one?
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lookup string format
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > >we had already been over the best way to format
> > > the lookup string back in august
> > On formatting, the consensus as I seem to remember was :
> > <domain> ":" <key>
>
> I'm slowly digesting the recent volume of discussions, but I
> just to toss in
> an idea on this specific issue.
>
> (1) There is the existing property convention, using the
> standard java qualified name convention, e.g.,
> org.apache.avalon.<local-name>
At least in reference to _Context_ keys, we seem to lean toward
the second option. In Parameters/Properties, there is no
standard other than the Java standard (at least that I am aware
of).
> (2) Alternatively, there is RFC 2141, which appears to be
> the direction you're indicating.
> (http://www.ietf.org/rfc/rfc2141.txt)
>
> As I understand it, Avalon has already gone over the choice
> between the
> existing "Java" convention and a <domain> ":" <key>
> convention, and Stephen
> indicates that he believes that the latter was chosen. Fine.
Right. It seems something that both Stephen and Peter agreed on,
which is a good thing. I have no problems with it, and am willing
to move toward its use.
> However, if Avalon is going to adopt a <domain> ":" <key>
> notion, then I
> suggest that Avalon vote to adopt RFC 2141, and incorporate
> it by reference.
> Incorporating RFC 2141 will save you from having to go
> through all of the
> arguments already dealt with during the production of the
> RFC, and provides
> more detailed and specific information necessary for users
> and implementers.
+1 I agree.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>