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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Re: from and to role proposal


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


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


Powered by eList eXpress LLC