Subject: RE: Interface Primitives Draft V021.
david, i did not say the things that you have just attributed to me. in an earlier message, i simply asked that you work directly with farrukh and scott to resolve a better way of handling "working with each other issues". i am ready to accept and review all input from anybody on this team and hope that you would feel the same way about reviewing input from me. most of the statements that you are addressing directly below came from one of farrukh's replies to you. i recommend that we "END THIS THREAD" now and ask that all on the Reg/Rep team dutifully review david's interfaces draft and consider its content for inclusion into the registry specification documentation that is currently under development and in review. tracing through the lengthy history of this "rich" thread, all problems seemed to have begun, when at least one participant did not understand how the interfaces draft document applied to the work at hand. i recommend that whoever does not understand what david what aiming at should simply ask david. joel -----Original Message----- From: David RR Webber [mailto:Gnosis_@compuserve.com] Sent: Wednesday, September 20, 2000 12:15 PM To: Munter, Joel D Cc: 'Farrukh Najmi'; Klaus-Dieter Naujok; ebxml repository Subject: RE: Interface Primitives Draft V021. Message text written by "Munter, Joel D" >-Ideas should be put on the table in their proper working group and positioned as a proposal. -They should not be (mis)represented in other working groups as works of the proper working group. -They should not contain misleading statements that position ones company's product or specs as ebXML's products and specs. -They should not contain technologies/protocols used by ones company as ebXML's supported and accepted technologies/protocols -They should not be done as parallel universes to officially sanctioned works in the proper working group <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Once again this is a total mispresentation of the facts. The information was VERY clearly annotated when posted to TRP - see below. Further - there is a continued attempt to misrepresent this as "company's product or spec's" and that is again simply not true. This is a set of ideas based off brainstorming around the TRP work, IETF DASL work, OASIS work and seeing how this might all come together and XML/edi work on simple mechanisms for business analysts and SME's. This was also stated in the draft itself. That is what TRP asked to discuss - the issues in using TRP to implement RegRep interactions. We need a start point on this to at least get some ideas and issues discussed. We can then accept or reject things in an open forum - and put together matrix of validation parameters and business functional requirements that we can assess the various technology options with. We still need to do that work. It is unfortunate that that process has been sideswiped by not reading what is being stated - but by unverified assumptions and prejudgement instead. Following on from today's RegRep conference call - I now have a better understanding of the .05 spec transport mechanism interactions. This was not at all clear from the spec's. As noted previously there is harmonization needed here between the level of technical details - and much better would have been a statement to that fact. ie. hello TRP - I have some input here in terms of the transport model that is a difference approach - that can use some of the details here, and once I've worked with David on that - then we will present something that is a balance. Standby please. DW. ================================================= reference: previously posted note to TRP ================================================= Attached is the first draft of interface spec's for RegRep using WebDav DASL - WARNING - this has NOT been reviewed in detail by RegRep yet. You will need to review the DASL spec's at http://www.webdav.org to understand the full fucntionality here - as I have assumed this knowledge. Also - I have NOT focused at all in harmonization with TRP - that's why I have the draft! First I just focused on solving the RegRep issues - and that is a pile of work still - especially on the Add side; Query is relatively clear. So - I'm looking for positive input here to augment the RegRep functional with better and more rich transport details.
Powered by eList eXpress LLC