I don't want to unnecessarily overload PartyId so that
it isn't always PartyId.
PartyId != Role
A Party can operate in multiple roles, and the same role
can be used by multiple Parties so it doesn't provide
a unique identification, which is the purpose of the PartyId.
The proposal I offer is backward-compatible (because Role
is optional) to a certain degree and yet it adds something
that RosettaNet believes it needs. It also makes life a little
easier to navigate within a CPA.
Cheers,
Chris
David Fischer wrote:
>
> 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: [mailto:]
> Sent: Wednesday, October 03, 2001 8:05 PM
> To: ebXML Msg;
> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
