Re: Glossary - Working UEB Stuff (Continued)

Continuing my comments[1]:

* Cutler, Roger (RogerCutler) <> [2003-02-04 14:16-0600]
> Actor - Same flavor but different in detail.  WSArch - is a "person"
> always a "legal entity"?  Is an actor really always a legal entity?  If
> the answers are "Yes", then I prefer the WSA definition because it is
> more specific and clear.  It needs grammatical tweaking -
> providers->provider, and->or??  It seems to me that web services are, in
> fact, agents.  So perhaps WSA might be changed to "An actor is a legal

I can't find actor defined in the WSA glossary. I think that we should
wait until David Booth comes up with diagrams for the architecture
document reflecting his roles presentation conclusions to try and
define what an actor is, based on the presence and role of actors in

> entity - such as a person or a corporation - that may be the owner of
> agents that either seek to use Web services or provide Web services.

Same comment.

> Agent - Different.  I like the current WSA definition, but there is also
> a current debate going on about that definition.  I find the UEB
> definition obscure and possibly not what we mean.

I like this definition which comes from the Web architecture document,
although I do have the same questions as Katia about "another" in the

|   agent
|          Program acting on behalf of another person, entity, or 
|          process.[Web Arch]

I will ask Ian Jacobs to clear up my mind.

> Party - Very similar, I think.  I like the UEB definition because it
> seems more specific to me  Is either, however, really any different than
> "actor"?  If so, how?

Actually, I had meant to remove party since it does not appear
anywhere else (anymore). I think that we have plenty of other terms
that we can use: client, system entity, node / SOAP node, end user,

> Relationship - I like this.

Do we need to define relationship?

> Repository - I kind of like this one, too.  I can't see the harm in
> having it.

I propose adding it.

> Requester/responder - Requester is good, responder is not.  I don't know
> if we need them or not.  Perhaps they are close enough to basic English
> to cut?

I don't think that a requester is necessarily initiating a _business_
transaction, or maybe even a transaction (well it depends what one
means by transaction, I guess). Anyway, I agree that this is basic
enough to maybe leave it out.

> Role - I like.

I propose adding it.

> Server - Cut.  We are using "client" in a different context, and I don't
> think we really talk about servers, do we?


> Software developer - Is this part of the intended audience?  Maybe it
> should be kept??  Maybe not.  I say cut.

It seems to me that software developers, when talked to, will
recognize themselves. :-)

> Service Provider (WSA) - This definition may come from some standard
> glossary, but it is not very good.  It's entirely circular.   Needs to
> be re-stated.

Agreed. I think that should be part of the results of DavidB's work on
roles. I will add an editor's note about that.

> Trading partner Yada - For some reason I think we should keep these, but
> I think that might not be other's opinion.

I would wait to have relevant text in the architecture document.

> URI - Looks OK to me, but no doubt the more pure at "Web-heart" will
> object strenuously for some reason.

I don't think that we need add a definition of URI in here. There
actually already is a pointer to RFC 2396 in the definition of a Web

> User Case - Looks good to me.  I think this is the same sense as we are
> using it.  We should also include Usage Scenario.

We should probably add this in the introduction of the usage
scenarios document, as I pointed out in my previous email.

> Protocol - We need a definition ... is this it???  "Capsules"????  What
> the heck is that??  "Messages types" ???  I think that this needs more
> work.  Can't we steal a definition of protocol from some other WG?

For some reason, I have the feeling that we don't need to define what
a protocol is. FWIW, here is what The Free On-line Dictionary of
Computing (12 Sep 2002) says:

|  protocol
|     A set of formal rules describing how to transmit data,
|     especially across a {network}.  Low level protocols define the
|     electrical and physical standards to be observed, bit- and
|     byte-ordering and the transmission and {error detection and
|     correction} of the bit stream.  High level protocols deal with
|     the data formatting, including the {syntax} of messages, the
|     terminal to computer dialogue, {character set}s, sequencing of
|     messages etc.
|     Many protocols are defined by {RFC}s or by {OSI}.
|     See also {handshaking}.
|     [{Jargon File}]

> Digital Signature - Good

I like RFC 2828's definition better:

| A value computed with a cryptographic algorithm and appended
| to a data object in such a way that any recipient of the data can
| use the signature to verify the data's origin and integrity.

We can add this one.

> Encryption - Good.

This RFC 2828's definition. We can add it too.

> Secure MIME - Good?

Secure MIME being a technology defined in RFC 2311 and not being used
in the architecture document, I wouldn't include it.

> SSL -- I like it.

SSL being a technology, I wouldn't define it in here.



Hugo Haas - W3C -

Received on Thursday, 6 February 2003 05:33:12 UTC