I am NOT addressing meta-info or meta-data concerns
Which is itself problematic ;-)
No it isn't. If you recall I had two objections before we could release Merlin. One was beefing up AMTAGS, and the other has to do with the way context keys are assigned. That is what this thread is supposed to be about.
I am recognizing the URN approach as useful, and I am trying to put together a solution that I think will help in the long term as well as the short term regarding HOW it is useful.
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.
?!? I don't understand your point. Furthermore, I think we are starting to go down a path that will derail any positive part of this discussion, so we'll try to pull in the rains a bit and focus on commonalities (IOW let's come back to this later).
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.
Here is how I see the distinction between Meta Info and Meta Data in Avalon terms--this is more generic than the way that it is defined within merlin.
Meta Info: Information about a component that is required for management,
tooling, or verification.Meta Data: Data about the Meta Information that can provide a larger picture
of the problem space.I think what you have defined in the Merlin Meta-Data subproject is more analogous to _directives_. I.e. how to dynamically populate default entries for the context. Perhaps we could call them Meta-Generators or Meta-Directives? Either way, I am trying to separate definition (interface)/solution so that we can enhance the framework at a later time for the unique requirements of container extensions.
3) A component should be able to declare its dependence on a namespace
-1 NO BAD WICKED EVIL :-)
So you are saying that "import" statements are bad, wicked, and evil?
Getting back to the meta-info extensions which we are not going to address right now, we need a way to signify to the container that the component expects certain aspects to be parsed. If the container knows that there are other namespaces (i.e. like the "instrument" example or even better the "management" example) that are important, there is a likelihood that the component will not function properly if the logic to handle that concern area does not exist.
The container needs to know what and how to address that issue. However, since we are most concerned about the pure Avalon space we can address that later. The *reason* I want to bring it up now is so that we are aware that we have an option to define namespaces for concern areas, which will allow us to define certain concern areas that are not shared accross all environments and define the context entries in those namespaces.
It is my expectation that in the short term, the context entries will continue to be defined by the present methods (Fortress assumes the container is omniscient, Merlin uses the meta-directives, Phoenix is somewhere in the middle). The important thing is that the container can authoritatively say that it can supply the known contracts for the concern area.
Start thinking about namespaces as interface definitions for concerns that cannot easily be expressed in code. For example, the "application" namespace could define context entries for how to get a work directory or the application's context directory. The "partition" namespace would define the context entries for the same thing.
The Container Extension concept would implement these namespaces in the future, but in the near term they are addressed the same way.
The concept of namespace in all the languages I know, as well as XML (not a language) provides a dual purpose:
1) To separate out a set of functionality/interfaces/declarations into a logical module--avoiding name conflicts.
2) To allow one module/namespace to use the facilities defined by another module/namespace.
In XML it is less clear because the namespace is not required to map to a schema definition--although in best practices it does. By declaring that we are using a namespace (in Java they are packages), we are declaring that there is a dependency from one namespace on another. That is another topic altogether. However I find that the concept has a real application here.
That is why I want to push as much out of the Avalon namespace as possible. It makes definition of the Avalon namespace easier, and it helps clarify the "avalon" interface to the components.
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.
That is an implementation concern. I am introducing the topic so that we can more easily scope what makes it to the Avalon namespace--knowing that we have the option to define the same thing in another namespace. We may already know several needed entries--but that does not mean that they should be put in the Avalon namespace by default.
We can talk about implementation details in the future. In the short term, let's concentrate on the interface.
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.
See above response to your -1.
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.
I am saying that the context entries and meta-info extensions should have a strong correlation. They should be part of a namespace which represents a non-code interface. We can theorhetically have 100 implementations that implement that concern area. I agree that we should worry about the mechanisms to accomplish this later. I think now we need to know how to declare the interface.
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.
Perhaps now that you know that I am only trying to address the interface side of the equation (i.e. certain context entries are required to implement this "interface") you can be in violent agreement. I think the opposition comes from trying to define implementation details too early.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
