Subject: Re: Single Registry Interface Proposal (ZIP)
Farrukh, For the record your assertions below are not an accurate record of the proceedings - but rather what YOU SAID in the meeting. There is a large difference between that. However - since I have now REMOVED myself from the RegRep WG, and notified Scott accordingly - since it is blatently apparent that whatever anyone says you are seeing RegRep now as 'your baby' and will produce the spec's however you (and Sun) see fit. Anyway - I'm not attempting to debate this - the underpinning for RegRep is basically sound as derived from the OASIS model, and therefore should not fail given due diligence and completing and refining the work to date. Basically - there is much detail that is poorly understood and documented but I'm sure it will be figured it out in due course. So - best wishes - I'm currently writing more Java code to complete and extend the implementation of the 08 spec's - warts and all - and will continue to track and implement the spec's as and when you update them and publish them. In the meantime - see notes below, and I'll see you in Vancouver. Thanks, DW. ======================================================= Message text written by Farrukh Najmi > This proposal was discussed by the team during the f2f meeting in Tokyo in the context of identifying issues and problems with the current specs. The team felt unanimously with the exception of the submitter that the existing DTDs were sufficient and adequate and that there was no need to consider these proposed changes further. >>>>>>>>>>> Correction - there were XML syntax errors identified in the current DTD's but the owner of these DTD's refused to acknowledge this - please refer to John Bosak to review the DTD's further. In general the consensus reached was that we have made tremendous progress (3 implementations of current Registry specs were shown at Tokyo POC with any client to any service inter-operability). That the specs work, is obvious. That they could be improved and made clearer, is also obvious. The team decided that we will not restart from scratch. Instead we took an approach to identify holes in current specs and fill them. >>>>>>>>>>>>> What this means is unclear. There was no formal issues list produced - but there was a lot of hand-waving. During the f2f we filled all holes (there were very few) identified in the information model spec. Yutaka and I then updated the spec overnight based on the latest work during the f2f. This was reviewed the next day and the team reviewed and approved the changes almost uninanimously) with 1 abstention. >>>>>>>>>>>>>> We should be given more details on this so that we can all review these details. This version will be distributed next week and will go to quality review. >>>>>>>>>>>>>> Good - we should also schedule a Conference call to discuss this prior too. Scott N. also instilled in the team a new sense of urgency to deliver specs quickly. Again this proposal had unanimous support. >>>>>>>>>>>>>>> I seem to recall it was Farrukh that decided we needed to rush forward. There was no vote taken on this - since I believe there would have been serious reservations to rushing ahead without at least identifying issues and known gaps. Thanks to Scott and Yuta's leadership we were able to make tremendous progress during the week. I am very pleased that we now have a phased delivery matrix which clearly defines a roadmap for what we need to deliver and by when. The train does not end at Tokyo. Onwards to Vancouver! >>>>>>>>>>>>>>>>> Train analogues are not good ones here. DW.
eList eXpress LLC