Berin Loritsch wrote:

Stephen McConnell wrote:


You get very defensive everytime I mention Merlin in light of Phoenix
and Fortress. What's the deal?


I think your assertions on thread have been missleading.


That statement seems to insinuate that I am intentionally being misleading.
I am not, furthermore, I do not see where I am being misleading. Disagreement
does not equal misleading.


Berin:

I seems that you want turn anything I say into a personal attack. I'm not attacking you. I said that your assertions on the matter of divergence were misleading. I said this because you were conveying information which in my opinion was and remains just plain incorrect. In doing so I happen to think your misrepresenting the current status of things related to Merlin development. You have said above that you do not see where you are being misleading.

Let me detail this for you.

You made a statement suggesting that Merlin was divergent from Phoenix and Fortress with respect to component definition. You did not provide any details and the time, but after being pressed on the subject, you raised two points concerning (a) the application of URNs within Merlin and (b) non-conformance with AMTAGS. I responded - pointing out to you that the claims you were making could not reasonably be framed as diverse together with the reason why. I will not repeat everything from that message - but instead - I will try to explain to you why your conclusions are misleading.

Firstly the subject of the usage of URN patterns within Merlin. You assert that because the Merlin implementation does not follow letter for letter existing practices - that it is divergent. This is grossly misleading because in-fact Merlin is neutral with respect to management of names. If you go over the tutorials on Merlin or take a look at the sources, you will see that Merlin places *no* restriction on a component author. Instead, the implementation enables arbitrary approaches. What is perhaps amusing in all of this is that the Merlin implementation is in fact the least diverse with respect to component/container contract and component implementation of any Avalon container. Your comments are misrepresenting this reality and creating a false and negative impression.

Your second point attempted to correlate that fact that because the Merlin implementation was not embracing an insufficient AMTAGS proposal, that Merlin was therefore diverse. This is misleading - the truth of the matter is the AMTAGS proposal as it stands insufficient, as you are well aware. This is not a question of being diverse - it is a question of insufficiency of a specification to meet operation requirements.

Finally - I would appreciate it if you could drop the "steve's being defensive" thing. This is not being defense - it is correcting a mistake you have - presumably arising from inaccurate or incomplete assumptions you have about the Merlin platform. If you wish to avoid similar patterns in the future - you may want to try to avoid the use of negative generalizations.

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]



Reply via email to