RE: ebXML Representtion of Metadata

[srh@us.ibm.com]

|<Scott>When I talk about bridges, I could easily bridge between an XML
|architecture to RPC, however, there is more to bridge in the SOAP
|specification than just XML.  Specifically the argument types, and the
|permissible types between DCOM, CORBA, etc.  I remember that the WebBroker
|note went into the "type mapping" in painful detail, and that is why it
|failed.  Why should SOAP detail these types at all, versus just
referencing
|a DTD or Schema that the "type" must adhere too?   Its really that
|simple.</Scott>

Yep, technically could be that simple and flexible.

Detailing the type representation is a tradeoff between
type structural representation flexibility and specifying a [constrained]
fixed structural representation
that will likely result in increased tool support from vendors and fixed
implementation language
mappings.

A tradeoff, as always. Endless flexibility has it's disadvantages as well
as advantages.

-- Eric, as we (IBM) have in the past, and continue to, support IIOP, this
space  is operating under
"no shared middleware" [can not require a CORBA ORB at both communication
ends].

Thanks,
Scott R. Hinkelman
Senior Software Engineer
SWG XML/Java Solutions/Standards
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



"Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>@lists.oasis-open.org
on 05/30/2000 11:41:37 AM

Sent by:  owner-ebxml-architecture@lists.oasis-open.org


To:   "'Eric Newcomer'" <eric.newcomer@iona.com>
cc:   ebXML-Architecture List <ebXML-Architecture@lists.oasis-open.org>,
      ebxml-core@lists.oasis-open.org
Subject:  RE: ebXML Representtion of Metadata




<SNIP>
Actually I see SOAP as supporting this type of interaction.  There was a
considerable discussion during the V1.1 work about this, and I think the
result was embracing both styles of interaction -- pure or typical RPC with
formatted interfaces and generic XML message passing.</SNIP>

<Scott>No problem here.  I am totally supporting the intent.</Scott>

<SNIP>
Regarding the "bridge" concept, we definitely agreed SOAP as it stands is
primarily effective as a bridge technology -- bridging portals or object
models across the Internet. As a CORBA vendor we would recommend IIOP
across
the Internet for a full-function protocol (as MSFT might similarly
recommend
DCOM I suppose), but we are facing the reality that the Internet has
different qualities and characteristics than an intranet.</SNIP>

<Scott>When I talk about bridges, I could easily bridge between an XML
architecture to RPC, however, there is more to bridge in the SOAP
specification than just XML.  Specifically the argument types, and the
permissible types between DCOM, CORBA, etc.  I remember that the WebBroker
note went into the "type mapping" in painful detail, and that is why it
failed.  Why should SOAP detail these types at all, versus just referencing
a DTD or Schema that the "type" must adhere too?   Its really that
simple.</Scott>