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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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


Subject: Re: prototype proposal update




Nick, good job on the demo doc.
Here are some quick points:

Fixes:

-> add the "v1." in front of CustProfileUpdate in the intent.

-> remove the OTA <OTA_v1 ..........> and <v1.Content.........> tags from
the ebXML payload and paste in:
   <OTA_v1 Target="Production" GeoCode="+4256-1482">
      <v1.UniqueId>
        <v1.ResourceId>5172806</v1.ResourceId>
      </v1.UniqueId>
      <v1.Verify>
        <v1.CustProfile ShareAllMarketInd="No" ShareAllSynchInd="Yes">
          <v1.Customer>
            <v1.Cust.PersonName NameType="Default">
              <v1.PersonName>
                <v1.Person.NameTitle>Mr.</v1.Person.NameTitle>
                <v1.Person.GivenName>Scott</v1.Person.GivenName>
                <v1.Person.MiddleName>R</v1.Person.MiddleName>
                <v1.Person.Surname>Hinkelman</v1.Person.Surname>
              </v1.PersonName>
            </v1.Cust.PersonName>
            <v1.Cust.Telephone PhoneTech="Voice" PhoneUse="Work">
              <v1.Telephone>
                <v1.Phone.AreaCityCode>111</v1.Phone.AreaCityCode>
                <v1.Phone.Number>111-1111</v1.Phone.Number>
              </v1.Telephone>
            </v1.Cust.Telephone>
          </v1.Customer>
        </v1.CustProfile>
      </v1.Verify>
      <v1.Set>
        <v1.CustProfile>
          <v1.Customer>
            <v1.Cust.Telephone PhoneTech="Voice" PhoneUse="Work">
              <v1.Telephone>
                <v1.Phone.AreaCityCode>112</v1.Phone.AreaCityCode>
                <v1.Phone.Number>111-1111</v1.Phone.Number>
              </v1.Telephone>
            </v1.Cust.Telephone>
          </v1.Customer>
        </v1.CustProfile>
      </v1.Set>
   </OTA_v1>

Industry (verticals, but a better term) Migration points to an ebXML
Transport Infrastructure:

1) Industries would drop any industry-defined message type, such as that
indicated
by the "RQ" at the end of the original OTA <v1.CustProfileUpdateRQ> tag,
and
express this in the ebXML MessageType element. Note that OTA maintains
using it's industry-specific approach to versioning the OTA intention.
2) Industries would load the ebXML payload with the remaining industry
content. This
would mean dropping any industry-defined 'method or intention' and message
type, such as the
OTA <v1.CustProfileUpdateRQ> tag since this is to be defined in the ebXML
header.
3) Other infrastructure information accomodated by the ebXML Transport
level defined
by an industry such as the TimeStamp attribute
from the original OTA top document element.........
<OTA_v1 Timestamp="2000-04-25 12:54:55.0" EchoToken="228722"
Target="Production" GeoCode="+4256-1482">
should be removed (given the same semantic as the ebXML Transport) and
expressed
into the ebXML Transport headers. The OTA EchoToken is in the same
situation
because we can accomodate this in ebXML with the MID field that expresses
the
associated message Note we are not showing these in the demo.
4) An Industry may need to maintain information important to the industry
once
defined in perhaps a top industry root element with in ebXML payload. The
examples
in the case of OTA are the the GeoCode and Target attributes on the
original OTA_v1 top tag.
These are now expressed within *what has now become the OTA payload top
tag* :
<OTA_v1 Target="Production" GeoCode="+4256-1482">.
Note that the TimeStamp and EchoToken are removed since the ebXML Transport
supports
the same semantics.

A prime selling point that is evident in the demo of the ebXML Transport
(not complete for all of ebXML):

+ The ebXML Transport level provides a cross-industry approach for defining
infrastructure
constructs commonly defined by, or being defined by, industry-specific
efforts. The ebXML
Transport can free industry-level efforts from addressing
infrastructure-level constructs for
needed for commercial-level messaging.

Nick, I can speek to the detail in Brussels if needed.

Scott R. Hinkelman
Senior Software Engineer
XML/Java Solutions/Standards
Architecture and Development
IBM Austin
Office: 512-823-8097 TieLine: 793-8097
Home: 512-930-5675, Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074




[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