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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: re: POC proposal from BP/CC


Message text written by Karsten Riemer
> 
Hi,
On behalf of BP and CC teams I have submitted the attached proposal for a
Tokyo demo to the Proof-of-concept (POC) team. We had a discussion about
this
in this Monday's BP meeting, and I agreed to just post the document on the
ebXML server. However, several people have already asked me for a direct
copy
so I am attaching for general distribution anyway.

thanks,
-karsten


<<<<<<<<<<<<<<<<<<

Karsten.

I'm sorry to rain on the party a bit - but WHY!!!???!!!

We agreed in San Jose that this was going to be a joint effort between
BP/CC/TPA/RegRep.

We also agreed that the approach presented on Thursday was OK as
a first draft.

I just spent all day working on this - posted it - came on line - and found
you had done something else.

Now we have two proposals and confusion.

The situation is not a complete disaster - but the central difference 
seems to be the UML tool.

I'd submit that the UML tool is NOT appropriate.  First ebXML is 
supposed to be generally accessible.

Martin Bryan already has a simple form tool to register content done,
and continuing down this path makes something that average
people can access.  Having to learn UML to do ebXML is not
in the requirements document anywhere.

We need to show that basic business skillsets can get this done.

The UML should be handled as a separate related effort as
I noted in my draft as a vendor specific extension to ebXML. 

I'm happy for you to show that your UML tool can interface
into ebXML - but not as part of the main demo'.   What Klaus
called for is vendors to announce tools that do ebXML - that
seems appropriate here.

Anyway - this issue aside I believe we can work in the rest
of what you have into the demo' proposed in San Jose.

I'd much prefer to see CC/BP focusing on Specifications for
XML content structures that will implement and drive the demo'.

Seems like we are close on being able to focus on that.

RegRep interfacing should be defined by the RegRep team,
I'm having the same issues with TRP - so we are getting
this rapidly tackled.  The issue your proposal raises is the
same - what QoS (quality of service) will the RegRep part
of the demo' provide?  We have answers coming on that.

Thanks, DW.



Tokyo-POC-01.ZIP



[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