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 12:58:28 UTC