RE: from and to role proposal

[David Fischer <david@drummondgroup.com>]

Looks OK.

Couldn't you do the same thing without any changes?

	<eb:MessageHeader>
		<eb:From>
			<eb:PartyId>urn:duns:123456789</eb:PartyId>
			<eb:PartyId type="Role">fromRole</eb:PartyId>
		</eb:From>

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
Sent: Wednesday, October 03, 2001 8:05 PM
To: ebXML Msg; ebxml-cppa@lists.oasis-open.org
Subject: from and to role proposal


All,

Following on today's discussion, and in light of the fact
that Arvola has identified a concern with regards to
mapping RNIF2.0 onto the ebXML Message Service,
I would propose that we add a Role element as a child of the
MessageHeader/To and MessageHeader/From elements respectively.

The value of the Role element is the value of the corresponding
toAuthorizedRole and fromAuthorizedRole attributes of the
BusinessTransactionActivity element of the BPSS that is
identified/referenced by either the RequestingBusinessActivity or
RespondingBusinessActivity element of the BPSS as appropriate.

It should probably be modelled similarly to the Action element
e.g.

	<eb:MessageHeader>
		<eb:From>
			<eb:PartyId>urn:duns:123456789</eb:PartyId>
			<eb:Role>fromRole</eb:Role>
		</eb:From>
		<eb:To>
			<eb:PartyId>urn:duns:987654321</eb:PartyId>
			<eb:Role>toRole</eb:Role>
		</eb:To>
		...
	</eb:MessageHeader>


The XSD for this change would look like the following:

	<element name="Role" type="tns:non-empty-string"/>
	<element name="To">
		<complexType>
			<sequence>
				<element ref="tns:PartyId" maxOccurs="unbounded"/>
				<element ref="tns:Role" minOccurs="0"/>
			</sequence>
		</complexType>
	</element>
	<element name="From">
		<complexType>
			<sequence>
				<element ref="tns:PartyId" maxOccurs="unbounded"/>
				<element ref="tns:Role" minOccurs="0"/>
			</sequence>
		</complexType>
	</element>

I've made it optional for starters. We can agree on whether or not to make it
REQUIRED. I think that it should probably be optional as there may be cases
where it is not needed.

As to spec language, I propose the following changes:
==========================================================================
to line 696 add the following:

	... The From and To elements MAY also contain zero or one Role child
	element that, if present, SHALL follow the last PartyId child element.

Following line 722, add a new section entitled Role element that has the
following
content:

8.4.x Role element

The Role element identifies the authorizedRole of the Party that is
sending (when present as a child of the From element) and/or receiving
(when present as a child of the To element) the message. The value of
the Role element is a non-empty string which is specified in the CPA.

[ED NOTE: do we need to be more specific as regards to exactly where
this value is sourced?]

==========================================================================

Of course, we would need to revise the relevant example fragments
to include a Role element(s) accordingly.

Comments?

Chris

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>