RE: Glossary - Working UEB Stuff

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