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

Fri, 13 Dec 2002 02:46:43 -0800 


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









--

To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>

For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


























					Reply via email to