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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: [regrep] Describing ebXML Reg/Rep - observations from Santa Fe


Regarding adoption:  I also believe part of the issue is the current
lack of adoption of Web services, due to issues such as security.  A
*loose* analogy might be that when the travel industry is suffering, the
luggage makers suffer.  

I predict that with initiatives such as WS-Security and the new W3C Web
Services Choreography Working Group underway, we will see in the coming
years a spike in the adoption and use of Web services, which will lead
to a increase in usage of registries not only for the storage and
maintenance of Web service information, but also the artifacts (e.g.
schemas) that describe/validate the Web service payload information, as
well as the entities (CPP/A) that support the collaboration.

Joe

Matthew MacKenzie wrote:
> 
> Max,
> 
> You make some great points, but I think that a lot of our problem is a
> general lack of people willing to roll up their sleeves and get all of
> the work done.  Compare this group's roll call to UDDI's, and remember
> that UDDI's scope is much more limited than ours.  UDDI has big
> marketing bucks behind it (read: MSFT & IBM), supplying a very good
> reason for people to step up and get it done.
> 
> What did we learn from Betamax and VHS?  Beta was better technically,
> but VHS machines are what you are replacing with DVD players today.  We
> need to spend some serious time on evangelizing regrep to the developer
> and vendor community, IMHO.
> 
> Matt
> 
> On Wednesday, Jan 29, 2003, at 18:47 America/Vancouver, Max Voskob
> wrote:
> 
> > Hello dear RegRep TC!
> >
> > Sorry for annoying you with my opinions, but here I just can't stay
> > silent
> > :)
> >
> > First of all, I support Erik in his observations.
> > Second, why do u want everyone to be smart? I don't want to be smart -
> > I
> > want things around me to be smart, easy to operate and understand.
> > Confused
> > where I'm coming from? Read this book
> > http://www.amazon.com/exec/obidos/tg/detail/-/0465067107/
> > qid=1043893177/sr=1
> > -1/ref=sr_1_1/102-5762810-0332102?v=glance&s=books
> >
> > To be closer to the point, I have to say that if one wants his
> > creation to
> > be used (adopted?) then one has to make it simple to use and
> > understand.
> > About a year ago I had an assignment to choose a Registry/Repository
> > for one
> > of our clients. That ultimately lead me to this TC. But think how an
> > average
> > busy IT specialist makes his research! I see a name "XML Registry". Do
> > u
> > expect me to go thru a 300 page manual to understand what it is and if
> > it
> > can work with any other object types? The average fellow would hardly
> > move
> > further than the executive summary.
> >
> > We had a very useful feedback from an outsider. Don't make him feel
> > ashamed
> > that he didn't read the spec - he doesn't have to!
> >
> > If I can't set up time for my alarm clock it's not my fault. It is a
> > designers fault. They didn't make it easy to operate. Same thing
> > applies
> > here.
> >
> > If someone says that your creation is hard to use/understand then I'd
> > think
> > twice and seek another opinion to make sure that that someone is an
> > exception, not a rule, unless I don't care.
> >
> > Cheers,
> > Max Voskob
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> > To: "Still Erik R" <erik.r.still@boeing.com>
> > Cc: "OASIS regrep" <regrep@lists.oasis-open.org>
> > Sent: Thursday, January 30, 2003 2:35 PM
> > Subject: Re: [regrep] Describing ebXML Reg/Rep - observations from
> > Santa Fe
> >
> >
> >> Erik,
> >>
> >> Thank you for your feedback (you must be a colleague of Kathyrn's).
> >> Some comments:
> >>
> >> #1 below:
> >> <Excerpt>
> >> It seemed helpful to clarify that an ebXML Registry does not
> >> necessarily
> >> use XML in its implementation, and that its contents do not need to be
> >> restricted to XML artifacts.
> >> </Excerpt>
> >>
> >>> From the RIM spec:
> >>
> >> "The registry provides a stable store where information submitted by a
> >> Submitting Organization is made persistent. Such information is used
> >> to
> >> facilitate ebXML-based Business to Business (B2B) partnerships and
> >> transactions. Submitted content may be XML schema and documents,
> >> process
> >> descriptions, ebXML Core Components, context descriptions, UML models,
> >> information about parties and even software components."
> >>
> >> This is made quite clear in the spec - are you suggesting then that we
> >> emphasize it whenever we present the Registry specification in
> >> presentations?  If this was not emphasized at the conference, I can
> >> definitely understand as the *main focus* of the Registry architecture
> >> is, after all, XML.
> >>
> >> #2 below:
> >> <Excerpt>
> >> 2.  Some people seemed to have the impression that the RIM was
> >> essentially a software package that could be simply installed.  It
> >> seems
> >> important to be clear that the RIM is a model and a standard - a level
> >> of abstraction above any actual implementation of the standard.
> >> </Excerpt>
> >>
> >> I don't doubt even for a picosecond your impression of the attendees'
> >> reaction, but it does surprise me given that the "M" in "RIM" should
> >> really speak for itself (i.e. it is a "M"odel).  Would you be willing
> >> to
> >> elaborate as to why you feel that people had this very incorrect
> >> impression?
> >>
> >> Thanks,
> >> Joe
> >>
> >> "Still, Erik R" wrote:
> >>>
> >>> Having attended the Open Metadata Registries conference in Santa Fe,
> >>> I
> > have some observations regarding
> >>> the presentation and description of ebXML Reg/Rep and RIM that might
> > have some bearing on the understanding
> >>> and acceptance of these standards and specifications among the
> >>> broader
> > metadata community:
> >>>
> >>> 1.  For the people not familiar with an ebXML Registry, there seemed
> >>> to
> > be some confusion about the relationship
> >>> between XML and the Registry.  It seemed helpful to clarify that an
> > ebXML Registry does not necessarily
> >>> use XML in its implementation, and that its contents do not need to
> >>> be
> > restricted to XML artifacts.  The ebXML
> >>> label suggests things about the Registry that are not true, and may
> > cause some people to dismiss an ebXML
> >>> Registry because they are "interested in metadata, but not XML".  In
> > presenting the ebXML Registry spec,
> >>> it is important to explain what ebXML is, and it's relation to the
> >>> spec.
> >>>
> >>> 2.  Some people seemed to have the impression that the RIM was
> > essentially a software package that
> >>> could be simply installed.  It seems important to be clear that the
> >>> RIM
> > is a model and a standard - a level of
> >>> abstraction above any actual implementation of the standard.
> >>>
> >>> I expect that it is not necessary to reiterate such points within
> >>> this
> > community.  But when presenting the
> >>> ebXML Reg/Rep to others, making these issues clear up front will go a
> > long way in reducing confusion and
> >>> gaining understanding and acceptance.
> >>>
> >>>         - Erik
> >>>
> >>> Erik Still
> >>> erik.r.still@boeing.com
> >>> CENTRAL Registry
> >>> Boeing Library Services
> >>>
> >>> ----------------------------------------------------------------
> >>> To subscribe or unsubscribe from this elist use the subscription
> >>> manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano



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


Powered by eList eXpress LLC