- From: Burdett, David <david.burdett@commerceone.com>
- Date: Tue, 11 Mar 2003 10:08:15 -0800
- 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 ways: 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. David [1] Thread on Application Protocol Definition http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/thread.html#423 -----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. Frank On Tuesday, March 11, 2003, at 06:51 AM, Cutler, Roger (RogerCutler) wrote: > 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