[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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC