W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2003

RE: Mapping Specs to the Architecture

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 11 Mar 2003 10:08:15 -0800
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D17F4@C1plenaexm07.commerceone.com>
To: "'Francis McCabe'" <fgm@fla.fujitsu.com>, "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
Cc: "Newcomer, Eric" <Eric.Newcomer@iona.com>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org

I agree that mapping specs to the architecture is a good idea, however I
would suggest that we use three principles to help us identify the
specifications and the boundaries of what each should contain:
1. Does it need standardization? In my opinion the ONLY reason for
developing a standard is because it improves interoperability and therefore
reduces cost. We should look at each area in the architecture and identify
how interoperability will be improved and how the users of the standard will
realize lower costs. If costs are not significantly lowered, then there is
no need to develop a specification. For example, I am not sure that business
process languages that define how you operate business processes *within
your organization* need standardization.
2. Is it self-contained? Does the functionality contained with the scope of
any particular standard *have* to be used together. If there is a need for
functionality to be used separately, then someone will invent another spec
to do this at some point. The best example of this is the security and
reliable messaging functionality within ebXML messaging which is now largely
duplicated by WS Security and WS Reliable Messaging TCs within OASIS.
3. What are the dependencies? Some specifications are dependent on other
specifications. We need to identify the layering that is required and the
dependencies of one specification on another. Some work on this has already
started [1]

We can also use the idea of "does it need standardization" in two further
1. Have we thought of everything? By analysing the barriers to
interoperability, we can identify what needs standardization and check that
our architecture is complete. However to do this we need some use-cases to
examine to identify where barriers might exist.
2. Are specifications being developed with the right priority? By
identifying where there is the greatest scope for lowering costs we can
identify which standards should be developed first.

Hope this helps.


[1] Thread on Application Protocol Definition

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Tuesday, March 11, 2003 9:22 AM
To: Cutler, Roger (RogerCutler)
Cc: Newcomer, Eric; Champion, Mike; www-ws-arch@w3.org
Subject: Re: Mapping Specs to the Architecture

I think that this is a good suggestion. A friendly amendment would be 
to draw a cloud around parts of the diagram that related to a specific 
specification. I will have a go at doing both.


On Tuesday, March 11, 2003, at 06:51  AM, Cutler, Roger (RogerCutler) 

> Well, that's one possibility.  I was thinking more along the lines of 
> taking the complicated diagram -- the one with Agent, Service, Legal 
> Entity, Goal etc -- and doing something like coloring boxes to 
> indicate spec residence.  For example, a box could be green if there 
> is a spec, orange if there is a WG/TC and blank if not.  Or the 
> name(s) of the spec(s) could be put into the boxes with a similar 
> color code.
> I'm not suggesting that the complicated diagram should have these as a 
> normal part -- I'm suggesting using it as a template for a special 
> "spec coverage" diagram.
> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> Sent: Tuesday, March 11, 2003 12:50 AM
> To: Champion, Mike; www-ws-arch@w3.org
> Subject: RE: Mapping Specs to the Architecture
> I'm not entirely sure, either, although this is consistent with the 
> intention of one of the original diagrams I produced (before the 
> "triangle" diagrams) -- as attached.
> I know this isn't perfect, and may not be what we Martin was referring 
> to when he said we needed a "stack" diagram, but maybe we could review 
> this again and think about improving it toward becoming this type of 
> diagram (which by the way I agree we should have, if that wasn't clear 
> before).
> Eric
> -----Original Message-----
> From: Champion, Mike
> Sent: Monday, March 10, 2003 2:26 PM
> To: www-ws-arch@w3.org
> Subject: RE: Mapping Specs to the Architecture
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@chevrontexaco.com]
> Sent: Monday, March 10, 2003 2:13 PM
> To: www-ws-arch@w3.org
> Subject: Mapping Specs to the Architecture
> I had a chat with TimBL about the WS Arch work in which he asked a 
> very interesting question.  He wanted to know whether we were 
> producing a diagram that would make clear what parts of the 
> architecture currently have specs in place, what parts have specs in 
> progress and what parts need specs but there is nothing in sight.   
>  I say that kind of thing in "elavator speeches" describing what we 
> do, but I guess we've never really talked about it, made it a 
> requirement, or  put it in the document.  Maybe it's time to do so 
> :-)  It would be a good cross-check tbat we cover the ground defined 
> by all the specs out there, and would have good PR value.
Received on Tuesday, 11 March 2003 13:08:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:05 UTC