OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: questions on UMM parameters (Fwd)


I have re-read the UMM section on this, and still do not know the answers to
my questions in my e-mail below. I propose that the SpecSchema leave the
possibilities open, and people who use UMM to arrive at a SpecSchema can apply
the constraints in the UMM process. What I mean by this is that I propose that
all the parameters


will be available for use in either the requesting or the responding activity.
That will support more than the currently suggested allowable UMM patterns,
but will not prevent any of them.

The interpretation of the parameters are:

isAuthorizationRequired - when you send my activity a DocumentFlow, I will
authorize you against a list isNonRepudiationRequired - when my activity sends
a DocumentFlow I will save it as an audit trail before sending
timeToAcknowledgeReceipt - when my activity receives a DocumentFlow I must ack
within this time  timeToAcknowledgeAcceptance - when my activity receives a
DocumentFlow I must ack within this time  isNonRepudiationOfReceiptRequired -
when my activity receives a DocumentFlow I must send a signed ack within the
time required for timeToAcknowledgeReceipt above isIntelligibleCheckRequired -
when my activity receives a DocumentFlow I must validate its syntax before I
send a receiptAck back.

Please speak up if either my interpretation is wrong, or if you disagree that
all of these options should be open at both ends. Currently UMM does not
suggest acceptance from requester, but I don't see why that could not be a
future pattern, it is close to what the negotiation pattern was looking for.

As far as timeToPerform is concerned, I still think it applies only to the
transaction as a whole and should not be in the requesting or responding


>----------------Begin Forwarded Message----------------<

Date: Wed, 14 Mar 2001 12:40:26 -0500 (Eastern Standard Time)
From: Karsten Riemer <Karsten.Riemer@east.sun.com>
Subject: questions on UMM parameters
To: Karsten Riemer <Karsten.Riemer@east.sun.com>
cc: "Hayes, Brian" <Brian.Hayes@Commerceone.com>,
        "'Sharma, Nita'" <nsharma@netfish.com>,
        "'Bill McCarthy (E-mail) '" <mccarth4@msu.edu>,
        "'Bob Haugen (E-mail) '" <linkage@interaccess.com>,
        "'James Jamie Bryce Clark (E-mail) '" <jbc@lawyer.com>,
        "'Jim Clark (E-mail) '" <jdc-icot@lcc.net>, cory-c@dataaccess.com,

This relates to today's upcoming discussion. I am having difficulty
understanding the exact placement of some of the parameters in the UMM model
for the 'activities':

From UMM:

BusinessActivity (supertype) (to be renamed businessAction):


RequestingBusinessActivity (attributes in addition to the above):


RequestingBusinessActivity (attributes in addition to the above):



If a requesting activity has isAuthorizationRequired does it mean that you
must be  authorized to perform this activity, or that the request that you
send will be validated against a list of authorized identities? My confusion
is that I don't know if this attribute relates to the outgoing or the incoming

Can a requesting activity send an Acceptance? If not, then
timeToAcknowledgeAcceptance should be in only one of the activities. Which

When a requesting activity sends a receipt ack is it intelligible checked or
not? Should intelligible check be in both?

Is time to perform different for requesting and responding, if not, shouldn't
it be at the transaction level?

>----------------End Forwarded Message----------------<

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC