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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

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

Subject: RE: Single Registry Interface Proposal (ZIP)

This is correct.  

I too made the consession that we need to move forward with the current
services architecture, and this is due to the stated sense of urgency.
Generic interfaces are great, however, we are being criticized by the UDDI
initiative that our CURRENT interfaces are too generic, and UDDI interfaces
(find_business) are move approachable to programmers (VB-likes).  To
introduce a set of EVEN MORE generic interfaces will further alienate
people.  getItem() and getList() approaches lead to great architectures, but
we cannot afford the energy debating this.  It will jeopordize our go to
market strategy at this time.

(BTW, Antoine Lonjon is working on a mapping between the bp-cc work to UDDI
using our interfaces).

Let move forward.


-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Friday, November 10, 2000 2:36 PM
To: Philip Goatly
Cc: David RR Webber; ebxml repository
Subject: Re: Single Registry Interface Proposal (ZIP)

This proposal was discussed by the team during the f2f meeting in Tokyo in
context of identifying issues and problems with the current specs. The team
unanimously with the exception of the submitter that the existing DTDs were
sufficient and adequate and that there was no need to consider these
changes further.

In general the consensus reached was that we have made tremendous progress
implementations of current Registry specs were shown at Tokyo POC with any
client to any service inter-operability). That the specs work, is obvious.
they could be improved and made clearer, is also obvious. The team decided
we will not restart from scratch. Instead we took an approach to identify
in current specs and fill them. During the f2f we filled all holes (there
very few) identified in the information model spec. Yutaka and I then
the spec overnight based on the latest work during the f2f. This was
the next day and the team reviewed and approved the changes almost
uninanimously) with 1 abstention. This version will be distributed next week
will go to quality review.

Scott N. also instilled in the team a new sense of urgency to deliver specs
quickly. Again this proposal had unanimous support. Thanks to Scott and
leadership we were able to make tremendous progress during the week. I am
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!

Philip Goatly wrote:

> Hello Folks,
>     I am new to the forum. I am very disappointed with the above document.
>     If we are going to have any credibilty we MUST describe what we intend
> with clarity.
>     The document is full of unnecessary verbiage and mangled English.
>     Take one example:
> " 7) Provide a simple metaphor to migrate and express existing data
> dictionaries and related content such as COBOL copybooks, SQL table
> definitions, CICS structures, program data structures, business data
> dictionaries and similar information content quickly and easily into."
>   Help !!!! This is neither grammatical English nor is it comprehensible
> English.
>  If part of this document has been prepared by someone whose mother tongue
> is not English, please have it checked by a native English speaker.
> As an alternative let the author write it in their own language, then
> it translated by a translator whose mother tongue is English.
> Our specifications, and other documents, must be clear and unambiguous.
> are about communication of a grand plan. If communication fails we are
> I am sorry to have to start my membership of  the forum with a rebuke as
> above, because I think the whole initiative is admirable, and greatly
> needed.
> I would hate to find the initiative was failing because it is badly
> communicated.
> Sorry !!
> Cheers, Phil, Goatly (Bolero International Ltd)
> ----- Original Message -----
> From: David RR Webber <Gnosis_@compuserve.com>
> To: ebxml repository <ebxml-regrep@lists.ebxml.org>
> Sent: Saturday, November 04, 2000 5:35 AM
> Subject: Single Registry Interface Proposal (ZIP)
> The attached is the first draft and example DTD's.
> The idea is to create a simple single pair of DTDs
> for Requests to the Registry and Responses back.
> People can then use this pair to implement whatever
> use cases and extended function sets that they
> desire.
> This is the culmination so far of working on the OASIS
> Registry interface and creating an aligned interface
> for ebXML.  The ebXML interface is significantly
> simpler than the OASIS.  But it follows the same
> information model, which is really cool (since it means
> OASIS and ebXML Registries can be interoperable,
> and it also means people wanting extended functionality
> can potentially setup to an OASIS registry).
> Apologies for getting this out late, I've had to fight a
> heavy head cold the last two days; no fun.
> I will bring 20+ printed copies to Tokyo for those
> attending to review.
> As we are coming out post-PoC we should be able
> to apply lessons learned to the single interface model
> here, and make a simple and consistent way to
> access Registry.  I've already borrowed heavily from
> the earlier work leading up to the PoC - thanks for
> everyone's efforts on providing those materials.
> My sense is my first draft here needs work to
> polish and get the story consistent and easy to
> understand.  My goal was primarily to get the
> DTD's as exactly close as I could and clean
> and error free.
> I look forward to everyones input to these ideas
> so far.
> Thanks, DW.


[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