RE: Yet another attempt to fix D-AC004

Hi Mark,

Thanks for the feedback. Comments inline...

>> X 'is comprised of loosely-coupled components and their 
>interrelationships' 
>
>What does "loosely coupled" refer to here?  In my experience, the most
>common use is wrt coupling between interface and implementation, but it
>has other meanings.  We should be clear what we mean.

Well, my intention was that the components are decoupled relative to 
each other (a change in one component doesn't force a change in another
component) and also in the common use you describe above. If we can agree 
on that then I can try rewording this to make it clear.

>
>> with the following subordinate requirements (from 
>synthesizing D-AC004.2, 
>> D-AC004.3 and AR004.2):
>> 
>> AR00X.1 components are [minimally] defined in terms of 
>unambiguous, well-
>>         defined interfaces.
>
>An interface is definitely an important part of a component, but I
>wouldn't say that it defines the component.

I agree - that's why I threw in the bracketed 'minimally' term. I was
also thinking that descriptors like role and responsibilities should
be included, but I was first trying to translate the existing text 
in D-AC004.3.

>
>X.2 below says what I think needs to be said, so I'm not sure what X.1
>adds.
>
>> AR00X.2 component interfaces define their inputs and outputs 
>and also the 
>>         form and constraints on those inputs and outputs.
>
>What did you mean by "form" here?

This was from the original text. I left it in to hopefully solicit 
the author's intent and not throw out an expressed concept 
indiscriminately. 

>
>> AR00X.3 component relationships are described in terms of 
>messages and 
>>         message transmission protocols.
>
>I'm unclear what you mean by "message transmission protocols".  If you
>mean an application protocol, then I'd say that it defines the 
>interface
>more than any relationships.

The original text defines component relationships as 
1. messages 
2. protocols by means of which these messages are transmitted

I was trying to express this. Do you disagree with the level of abstraction 
here (component relationship) or the verbiage?

>
>> AR00X.4 messages are transmitted and consumed by the 
>component interfaces 
>>         that make up the architecture.
>
>Ok, but seems motherhood-and-apple-pie-ish to me.

True. Again just a reformulation of D-AC004.3. Also, to many of us, all these
are motherhood-and-apple-pie. Its just nice to start off with framing the 
scope and notation for our architecture with some common elements. 

>
>> AR00X.5 use XML based techniques for defining messages/protocols for 
>>         invoking web resources. (was D-AR004.3)
>
>Well, we've talked about using SMTP and HTTP for Web services, for
>example, and those don't use XML.  So I'd like to remove this one.  I'd
>suggest toning it down, but as it's a requirement, it wouldn't do much
>good to do that, so might as well remove it.

In the vein of toning it down, maybe replace 'use' with 'support'. 

>
>> As for AC004 ("does not preclude any programming model"), I 
>believe we 
>> should reuse the XMLP verbiage:
>> 
>> 'The specification will make reasonable efforts to support 
>(but not define)
>> a broad range of programming models suitable for the 
>applications intended
>> for XP.'
>> 
>> and say
>> 
>> AR004.1 Support (but not define) a broad range of 
>programming models suitable 
>> for Web Services applications.
>
>Sounds good.

Great!

Received on Tuesday, 25 June 2002 14:57:05 UTC