Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
I am hoping we were just crossing signals here. I may be having problems
expressing what is rolling around in my head--its real clear to me ;).
:-)
Hey - I know the feeling. I do think your overlaping meta info and meta data aspects - something that is real easy to do and something that takes a lot of time to seperate. Even Merlin is not perfect here (I can point you to Merlin level meta-info that is actually meta-data-ish). The imprtant things are to seperate "descriptors" from "directives". The "descriptors" define expectations - the directive define the solution. The composition package I've been working on is all about taking descriptors, pulling in directives, and from that building the information model. Is it a source for headaches - sometime yes - sometime no. The more practice the better you get.
Hopefully by starting out with a clean slate I can make it more clear. First, let me state what I am not addressing:
I am NOT addressing meta-info or meta-data concerns
Which is itself problematic ;-)
Second, let me state what I am addressing:
1) There should be a correlation between namespaces and container extensions
Not necessarily - consider the following:
@avalon.entry key="urn:whoever:whatever" type="org.whoever.Widget"
The solution to this constraint is constrained by the meta-info declaration but it does not require or impose any constraint on the meta-data used to resolve the constraint. I.e. the declaration of some namespace in meta-info has zero impact on what is possible in meta-data land. If there is no correlation (other than the constraint) we have a classic contract/implementation separation. What I'm trying to say here is that the notion of a shared namespace ties problem to solution – but they are separate concerns - descriptors in meta-info define the problem (constraints) - directive in meta-data define the solution. Problem and solution should not be linked by namespace.
2) A container extension should specify everything it provides
Define "container extension" in terms of meta-info and meta-data that preserves the seperation of problem/solution and we have a framework for problem identification and solution delivery.
Without that, the ingredients are missing.
3) A component should be able to declare its dependence on a namespace
-1 NO BAD WICKED EVIL :-)
So, while the topic I am trying to convey has implications that affect meta-info
or meta-data, I am not trying to specify rules for those concerns.
The topic you’re trying to address must be expressed in meta-info and/or meta-data. Without this the topic is too abstract to be able to enforce in an interoperable manner.
I am saying that a Container Extension should specify a namespace that uniquely
identifies that concern area. The Container Extension will look for
meta-information ONLY in that namespace, and it will provide context entries
ONLY in that namespace. That namespace is the same.
See -1 note above. These are separate issue - like interface and implementation.
Now, if we identify that as a good thing, we can address entire namespaces/
concerns with one Container Extension. It also gives us a scalable method
of apportioning the definition of the namespaces/concerns without overloading
the core Avalon namespace.
Problem is that the IF in your question above is a huge if.
For example, if I want to dynamically instrument a component, I would have
a set of attributes something like this:
/** * @instrument.sample name="Process Transaction Profile" type="time" */ public Response process(Transaction trans) { Response response = null;
// do stuff
return response;
}
I understand – your example is clear meta-info extension. You describing a component implementation that is capable of providing instrumentation for a particular profile and type. The Avalon component model knows nothing about instrumentation (today). What I am saying is that this is something we need to deal with *after* we get the basics in place. I fundamentally disagree that there is a namespace correlation because I believe this breaks info/data separation. What I would like to see if people doing stuff with the core model and from that we learn how to address these types of problems. I have a few ideas - but they are ideas that presume a good understanding of the meta info/data separation - and honestly, we (the community) are not there yet.
The "instrument" container extension would read and interpret that meta
information. Also, if there were any context entries associated with
instrumentation, then they would be defined by that same container extension,
and those context entries would begin with "urn:instrument."
0
So what I am really driving at is agreeing that non-core stuff should be
defined in a unique namespace, and all meta-info and meta-data specific
to that namespace should be provided by the container extension.
I do not want to define what the container extension looks like at this time, or the mechanisms used to provide the definitions.
A part of me is violent agreement - and another part of me is in violent opposition. I figure its going to take a while for me to reconcile these two - and I figure that successful and failed experiments by all of us will be an instrumental ingredient to that reconciliation.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
