Re: [Avalon4:PROPOSAL] Context Consensus (version 2)

Leo Sutic wrote:

>
>>From: Stephen McConnell [mailto:[email protected]] 
>>
>>>  In regards to future canonical key names, it is the intent
>>>  that the values placed in the context are runtime values that 
>>>  can only be provided by the container. The Context should 
>>>  not be used to retrieve configuration values or services 
>>>  that can be provided by peer components.
>>>
>>>
>>I recognize your concern, but I think it is problamatic.
>>
>>I have cases where I'm constructing components that end up in 
>>context. Its does not happen very often
>>
>
>That was my intent with the new text - basically saying that
>"this is what we recommend in general, but as always
>there are times when you have to do something else."
>

Problem is that it is statating that there is a notion of 
container-provided versus peer-provide - and that something I disagree 
with.  There has been a lot of disucussion about this and the notion of 
"not" declaring where something comes from.  A component should not care 
how context entries are resolved - and this text is implying that there 
are restrictions related to the sort of information your going to get 
from context in terms of where it comes from - and I think thats a bad 
thing.

>
>Can you think of a better way of saying it, if you agree
>with the sentence above?
>

Given that meta-info and standard attribute names can be shifted to a 
subsequent step, the issues your addessing here are:

   (a) convenstions concerning entry key naming
   (b) conventions concerning context usage

On the subject of (a) I think comes down to being explicit about 
recommending the use of RFC 2141and specifically declaraing the "avalon" 
NID.  On the subject of (b), I don't think there is anything that should 
be said.  So, if I were to propose something it would look like the 
following:

  Entry key names should conform to URN naming
  conventions specificed under RFC 2141 where the format of a
  URN is "urn:" <NID> ":" <NSS>.  NID is Namespace IDentifier,
  and NSS is Namspace Specific String.  The NID "avalon" is
  reserved for standard Avalon context key entries.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[email protected]
http://www.osm.net