Re: Single Registry Interface Proposal (ZIP)

[David RR Webber <Gnosis_@compuserve.com>]

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.