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] Implementing CCTS in Registry - further thoughts


Joe, 
Yup that jives with my understanding and as you say, if CC (and BP)
can't be intrinsic (ie. real business content) then ... well it comes
across sounding 'strange' till we can see all of the business level
semantic query services that will be needed to support the 'business
experience'.

-Dave


> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Monday, February 17, 2003 12:18 PM
> To: Dave Welsh
> Cc: Duane Nickull; Farrukh Najmi; Fuger Sally; David RR Webber - XML
> ebusiness; OASIS Registry List
> 
> Dave,
> 
> Thanks for your input.  I think we should clarify as to what we mean
by
> "first-class", so you can see if you still feel the same way
(apologies
> in advance if you already know this!).  By "first-class" we simply
mean
> having Intrinsic (pre-defined) object types within the Registry to
> represent Core Components and their associated entities - in the same
> way that we have pre-defined object types for Service, Classification,
> Association, etc.  If Core Components were to not be first-class, it
> would mean that they would be represented using Extrinsic objects -
much
> like CPA and CPP are represented.  One difference for implementations
> would mean that queries would be different - as shown in the 2 SQL
> commands I provided last week (second one used Slots).
> 
> - Joe
> 
> Dave Welsh wrote:
> >
> > -1
> >
> > I can imagine that not making the essential business artifacts 1st
class
> > might sound technically nice but we are trying to enable business.
> >
> > I think there will be a set of business focused use case 'asks' for
> > specialized business services we'd hope the Registry will provide;
to
> > make the business experience even more effective. Therefore, in the
> > interest of the business community, I'd like to suggest waiting for
the
> > CC and BP teams input before passing any judgment.
> >
> > Dave
> >
> > > -----Original Message-----
> > > From: Duane Nickull [mailto:duane@xmlglobal.com]
> > > Sent: Monday, February 17, 2003 11:58 AM
> > > To: Farrukh Najmi
> > > Cc: Fuger, Sally; Chiusano Joseph; David RR Webber - XML
ebusiness;
> > OASIS
> > > Registry List
> > >
> > > +1
> > >
> > > Farrukh Najmi wrote:
> > >
> > > > Your suggestion has definitely crossed my mind. I have asked
myself:
> > > > "maybe CCTS, BPSS, CPP/A are special and maybe we should give
them
> > first
> > > > class status?"
> > > >
> > > > After careful analysis I feel that it would be a mistake to give
> > them
> > > > first class status no matter how "integral" a part of ebXML they
> > are. We
> > > > still must not have a tight coupling to them in ebXML Registry.
Here
> > are
> > > > some reasons why not:
> > > >
> > > > -It is not necessary. No use case has been articulated that
cannot
> > be
> > > > met without having a binding to the generic ebXML Registry as it
is
> > > today.
> > > >
> > > > -It violates ebXML Architecture's goal of avoiding tight
dependency
> > > > between ebXMl specs (Duane can remind us of the exact verbiage I
am
> > > sure)
> > > >
> > > > -It is not a good design. A good design keeps layers one spec on
> > another
> > > > and avoids a circular dependency. CCTS should depend on ebXML
> > Registry
> > > > (which is a foundational spec) but not the other way around.
> > > >
> > > > -It tells others non-ebXML specs (e.g. HL7, OGC, OAG, etc.) to
"do
> > as we
> > > > say, not as we do". That would not only be be hypocritical it
would
> > > > create complexity due to special case handling resulting in
creating
> > two
> > > > ways of doing the same thing.
> > > >
> > > > I feel that this issue cuts to the very essence of the core
> > philosophy
> > > > of our ebXML Registry specifications (extensible, generic,
> > > > content-neutral architecture) and urge that we reach a common
> > > > understanding on this issue soon. To that end I propose that we
make
> > > > this the main/sole agenda item for our next TC meeting.
> > > >
> > >
> > >
> > > --
> > > VP Strategic Relations,
> > > Technologies Evangelist
> > > XML Global Technologies
> > > ****************************
> > > ebXML software downloads - http://www.xmlglobal.com/prod/
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC