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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-jc message

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

Subject: Comment on Item 4 in Karl's startup agenda

Excerpt from Karl's startup agenda:

"  4. There is need to create an ebXML Infrastructure Architecture.
the JC do this? or should we start a new TC for this purpose? [my
preference is to start a new TC; I would prefer to keep the JC as
lightweight as possible, and be for coordination only.] If a new TC,
could they do the Glossary also?"

I think that there is a need for coordination of the ebXML family
of specs, and related supporting specs, at the 2.0 level with respect
to web services. Specifically, the collaboration approach needs to
be {integrated with /reconciled with /differentiated from} the web
services approach with its UDDI,WSDL,SOAP core. Both web services
and ebXML now have a SOAP envelope shared. But WSDL embrances parts
of BPSS and parts (small part again) of BPSS. While I think that
web services aims for a much more "asymmetric" and dynamic setup 
(that is a web server just announces what it has to offer 
and how it does it) and leaves it to a client to take advantage 
of the service, ebXML is more geared toward configuring a stable
channel of transport,security options, dataformats, packaging that
will persist for ongoing conversations. Somehow these differences
need to be documented and their suitability discussed. Also, overall
business processes (involving consumer input and feedback and status
update) could integrate both web services aspects and ebXML backend
aspects. Registry has already engaged its RAWS initiative. CPPA is
entertaining a web services approach to aspects of negotiation (to 
have a more dynamic way to jump-start negotiation). I think that despite
the W3C unclarity about its Web Services directions, we need to get 
something in place to start mapping out an approach that would make
sense however the details shake out at W3C. However, I do not see
how to charter such an initiative, nor what its deliverables should
be. One glaring hole is how the "sister" spec -- BPSS -- will fare
compared with BPML, XLANG, and WSFL, and how that impacts the Oasis
side. So I would like to see an "architectural futures" initiative
that is preparatory for the actual architecture design effort.


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

Powered by eList eXpress LLC