- From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
- Date: Wed, 5 Feb 2003 12:30:53 -0600
- To: "Hugo Haas" <hugo@w3.org>
- cc: www-ws-arch@w3.org, "Duane Nickull" <duane@xmlglobal.com>
Basically agree with all your comments except maybe one. That one is the use case / usage scenario thing. I think that if it's not in the glossary it should at least be spelled out pretty clearly in the Use Case doc itself. I personally, being somewhat oriented to use cases, would like to see the terms included in the glossary and the general subject of use cases discussed, or at least referenced somehow in the document. Some more specifics, basically no arguments: Component - Personally I like the editor's doc definition least of all because it doesn't say very much. Element - Good rewording. <quote> > Reference Architecture - Awfully wordy. True, but I don't think it is an OK definition. </quote> Huh? Do you mean that you DO think it's OK? If so, OK by me. API - Actually, UEB just has a placeholder. If we need a definition of API we're going to need to work for it. Attribute - Agree. Choreography - Weeellll - kind of agree about passing stuff along but surely there is going to be SOME mention of choreography in the document. If so, it seems to me that at least one basic definition would be kind of nice. -----Original Message----- From: Hugo Haas [mailto:hugo@w3.org] Sent: Wednesday, February 05, 2003 11:58 AM To: Cutler, Roger (RogerCutler) Cc: www-ws-arch@w3.org; Duane Nickull Subject: Re: Glossary - Working UEB Stuff Hi Roger. * Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com> [2003-02-04 10:55-0600] > Following are my personal opinions about what do do with the merge of > WSA and UEB glossaries -- covering Architectural, General and > Choreography terms. That is, I got tired of typing when I got to > Roles. > > When there are multiple definitions of the same term I have tried to > indicate whether they are different or similar and have expressed a > preference. I am also suggesting which UEB terms NOT to include in > the WSA glossary, based on my rather vague perception of what terms > have been used in the WSA document. Thank you for your hard work. > Questions: > > 1 - Is this analysis useful? That is, should I continue? It is. > 2 - What process do we follow for deciding what to do? Hugo -- I'm > perfectly happy if you decide. Or if you really want me to you can > ship me the XML plus comments and I will try to implement what I > suggest modified by your comments. I am proposing to do the following changes to the document. When I agreed with you to remove/ignore a term, I have just omitted your reply. > Architecture - Similar but not identical. I like WSA-1, but I like > inclusion of "constraints" in UEB. RF seems to be a different style > from other definitions and the text of the WSA. Suggest one > definition: "The software architecture of a program or computing > system is the structure or structures of the system. This structure > includes software components, the externally visible properties of > those components, the relationships among them and the constraints on > their use." See "reference architecture" -- I think that the UEB > "architecture" is closer to the WSA "reference architecture". I am > not sure, however, that this distinction is actually maintained in the > WSA document. I like your rewording. I would propose replacing #1 by your proposed one. > Artifact - FINALLY a good definition of this word that keeps popping > up. I'd like to keep this definition and try to ensure that usage of > the term in the doc conforms to it. I am proposing to add it to the document as is. > Component - Similar. I like UEB best, WSA-1 next and RF least. > Again, there's nothing wrong with RF but it seems to be in a different style > than WSA. I do not understand the phrase "conforms to a prescribed > behavior common to all components within an architecture" in WSA-1. > Suggest using UEB. It seems very clear and correct to me. Note that the editor's copy has a third definition: A component is a unit of architecture with defined boundaries. > Conformance - Looks like a good definition to me. Is it needed? I > say cut. I don't think so, unless we use the word in the architecture document, but I don't think that it is something that we should define in our glossary. > Deliverable - Great definition. I don't know if we need it, but I > really like it. I don't think that we need it. > Data Type - Cut. I am also suspicious of this definition. If we want > to use, should check other W3C docs. Hmmm... I share your feelings about this one. Should we need one, we should have a careful look about this. > Design - Good definition, references "analysis" which I put in > "general terms". I say cut both unless we use these terms. I don't think we need this one. > Element - RF definition is not really a definition, it is sort of a > statement that seems to contain an implied definition. UEB definition > is cryptic. I don't really like either, but I guess I'd go with RF as > at least being comprehensible. I think that Fielding's dissertation excerpt could be reworded as: Element A part of an architecture (component, connector, or data). Relationships between elements are constrained in order to achieve a desired set of architectural properties. > Reference Architecture - Awfully wordy. True, but I don't think it is an OK definition. > API - Do we use this term? If so, I'd say a definition is > appropriate. I don't think we use it, but let this archived email be the record that there is a good definition of API available. > Attribute - Different. UEB is OOP-specific. WSA seems preferable but > needs work. I do not understand "Salient attributes of an object is > decided by the beholder", which at the least is grammatically > incorrect (subject-verb agreement - should be "are"). Maybe we can just drop the last sentence, "Salient attributes of an object is decided by the beholder". > Cardinality - good definition. Do we need? I don't think so, or at least not for now. > Document - Good definition. I think we need. OK, I propose adding it then. > Document Exchange - Horrible definition. Cut or improve. I don't think that we need this. > Electronic Commerce - cut? I guess. It does, however, contrast in an > interesting way with EDI. I don't think that we need to define electronic commerce: it is out of our scope. > EDI - I say keep. I think we use the term, and this seems like a > really good definition. I guess that this is used in the architecture document and in the usage scenarios document, so I propose that we use this one. > Identity - WSA definition flawed? Is it OK to use the word > "identifier" to define "identity"? It does look weird. I will try to find a better definition. > Implementation - Good. The NIST definition is indeed good. I propose we integrate. > Interface - Different. We've got three here, and I think all are > different. I like UEB-2 myself ("A named set of operations that > characterize the behavior of an element"), but I suppose we may want > to use the WSD definition because it is more specific to WS. The UEB > definition, incidentally, is hard to find because it is > mis-alphabetized after all the "international" stuff. "F" comes > before "n". The current one is tightly related to WSDL 1.2, since it separates operations, and transmission protocol and data format. I think that one definition which is missing is one in the context of components of the architecture. I think that we will need to work on this definition. > Message - Three definitions, all similar. I say keep WSA because it > is WS-specific. OK. > Message Yada-Yada - I say cut. Messaging Service and Messaging > Service Layer, however, are interesting. Do we use these terms? Actually, in the new draft of the architecture document, there is something about messages being the unit of communication of Web services. > MIME - I say keep. Hmmm... I don't think we need this. MIME is an acronym and an RFC (or a set of RFCs), it should be self-explanatory. As a matter of fact, a search in my favorite search engine gives me the same information. > Scenario - Interesting, but cut. Is this consistent with our use of the > terms "Use case" and "Usage Scenario"? I think it may be. I think we > should include "Use Case" and "Usage Scenario" in this glossary, since > we may not use them exactly in the same way as other people. I think it is, or it least for one of them. I am not convinced that we need a definition in the glossary though. > System - UEB seems to have two different defs. Is either consistent > with our use of term? Seems like System might be a good thing to > define, but this is confusing to me. I think that their system definitions are two more precise cases of our system entity definition. Now, another problem comes into the picture: what is the relationship between a system entity and a component? This is an open issue and is noted in the editor's copy. > Choreography - Different, though related. I like UEB better. I don't > see any reason to bring the concept of Turing completeness into the > definition itself. > > Interface Business Processes - in WSA. Do we really use this term? > This usage seems quite different from UEB, which makes me > uncomfortable. I'd like to consider cutting it or thinking about it a > bit more. > > Collaboration - I like it. > > Collaboration diagram - do we use this term and also "sequence > diagram"? If so, looks good. If not, cut. > > Collaboration protocol - Looks good. Do we need it? > > Collaboration Business Processses - In WSA. Why do we have this? I > think the UEB definitions in this space are clearer. I agree that all the definitions related to choreography would require more work. They were excerpted from the threads about choreography, and are not in sync with our document. I propose that, unless you are ready to tackle the whole thing now, we send the definitions to the Web Services Choreography Working Group, and try to reconciliate with the architecture document progressively. When the Web Services Choreography Working Group gets back to us, we can revisit the whole issue in depth. Continuing on to your second email... Regards, Hugo -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Wednesday, 5 February 2003 13:31:05 UTC