Glossary - Working UEB Stuff

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.

Questions:

1 - Is this analysis useful?  That is, should I continue?

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.

Architectural View - Cut

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.
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.
Behavior - cut.
Business Yada-Yada - Way too much from UEB for WSA.   I suggest that we
do not need any of them.  If we want to keep just a few, I suggest
"business", "business activity", "business collaboration", "business
document", "business partner", and "business transaction" as candidates.
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.
Concept - cut.
Conformance - Looks like a good definition to me.  Is it needed?  I say
cut.
Constraint ... - Cut.  Does not seem to be the same sense that we would
use the word.
Deliverable - Great definition.  I don't know if we need it, but I
really like it.
Data Type - Cut.  I am also suspicious of this definition.  If we want
to use, should check other W3C docs.
Design - Good definition, references "analysis" which I put in "general
terms". I say cut both unless we use these terms.
Design Pattern - cut.
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.
Reference Architecture - Awfully wordy.
Analysis - see design.  Cut.
API - Do we use this term?  If so, I'd say a definition is appropriate.
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").
Cardinality - good definition.  Do we need?
Document - Good definition.  I think we need.
Document Exchange - Horrible definition. Cut or improve.
Electronic Commerce - cut?  I guess.  It does, however, contrast in an
interesting way with EDI.
EDI - I say keep.  I think we use the term, and this seems like a really
good definition. 

Enumeration - cut.  Too detailed, I think.

Generalization - cut.

Geopolitical Context - CUT!  Refers to other definitions I did not
include.

Identity - WSA definition flawed?  Is it OK to use the word "identifier"
to define "identity"?

Implementation - Good.

Inheritance - cut.

Instance - cut.

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".

Message - Three definitions, all similar.  I say keep WSA because it is
WS-specific.

Message Yada-Yada - I say cut.  Messaging Service and Messaging Service
Layer, however, are interesting.  Do we use these terms?

Method, methodology - cut

Model, modelling tool - cut.

MIME - I say keep.

Naming ... - cut.

Operation - Different.  Keep WSA, if that is actually how we use the
word.  I am not really aware of using it, however, and it seems to me a
slightly counter-intuitive definition.

Operation Signature - CUT!

Package - cut.

Re-use - Cut.  Seems to me that have "use" twice in the definition is
not real good anyway.

Runtime - cut?

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.

Schema, Scope - cut.

Agreement - I do not think we would use the term in this way.  Cut.

Software Solution - Specification - Cut.

Synchronous - Too bad UEB didn't have something better.  Oh well.

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.

Template - cut.

Test - Not a good definition - "test" is a key word in the definition.
Tsk, tsk.  Cut.

Traceability - cut.

Web Service - Different. Our definition, flawed though it might be, is
much better than UEB.

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 Protocol Yada-Yada - Too much.  Cut.

Collaboration Business Processses - In WSA.  Why do we have this?  I
think the UEB definitions in this space are clearer.

Commitment, Common Business Process - Cut.