[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Common Business Objects
Paul: Thanks for the quick input. So far we have identified the terms "Core Components" and "CBO's". If we add the new terminology of "Data Composites" (or another name?), could you please provide us with an overview of how you see these as different than CBO's. To me, both CBOs and DCs are essentially the same syntactically however, they may be semantically different in the modelling domain. ISO/IEC JTC1 specifies data elements as the building blocks of all subject matter but I was unable to determine the rule structure for determining labelling of higher up item componentry. If each taxonomy may apply its' own rule set, it may lead to an extraordinarily large number of possible combinations of CC's for building DCs and CBOs. Duane Nickull "Paul R. Levine" wrote: > > I will look for CC and CBO in the glossary. However, I don't believe it's > understood by the CC or BP PTs that a CBO is an aggregation of CCs. The example > in Appendix B of a telephone number being a CBO, because it is comprised of core > components of a telephone number, is not correct. In SC 32 of ISO/IEC JTC1, > telephone number would be a data composite, comprised of data elements. In > ebXML terminology these could all be CCs, which could be the 'data part' or > partial 'data part' of a CBO. > > Regards, > > Paul > > duane <duane@xmlglobal.com> on 09/15/2000 12:18:43 AM > > To: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com> > cc: ebxml-stc@lists.ebxml.org (bcc: Paul R. Levine/Telcordia) > Subject: Re: Common Business Objects > > Dear all: > > I will probably be chastized for sending this message, but I am trying > in vain to end this discussion form now. We, the TA team, have ended up > in charge of the GLossary. While the glossary is not released as of > today, the terms for CC and CBO are clearly defined in the new TA > specification. The names can be changed later - do not worry about what > they may be called now. For all we know, they may be called "Foo" and > "Bar" (sorry to be archaic). > > The important issue is what they represent semantically. I think Scott > hit the point home when he placed this email. THe CBO's MAY take on the > contextual behaviour at run time. THe CC's do not. This is identified > in the appropriate sections of the new TA spec. Specifically, the > section dealing with "Implementation Issues" gives a clear description > for this issue. > > Please, lets all get on the same page. Let's also not argue about > changing the name of these things until we can all agree on what they > should do. > > Please give the new document a read today, even though it has not passed > the QA team at this point. I think it will give everyone a clear > overview. It has been written based on the collective input of all > involved. > > Duane Nickull > > > "Nieman, Scott" wrote: > > > > I am now catching up with emails haven been locked up in a hotel room > > for three days, and I uncovered this disturbing message. > > > > The message clearly illustrates that there is a complete > > misunderstanding of what a common business object is about. Perhaps > > its about communication of the definition of CBOs, or perhaps it is > > about mental blockages/ resistance to understand what software > > developers have embraced for years already. I don't have an answer to > > that. > > > > It is very unlikely that an object would be "sent" to a trading > > partner without engaging in a "conversation" within an established > > communications session (post whatever security clearances) - only a > > few programming environments allow that capability today. Typically, > > a CBO is specialized for an industry/company (whatever), and runtime > > instances will reside completely within the bounds of the corporate > > enterprise. CBO are NOT sent to another, however, their instances may > > be interacted with. It is NOT JUST about the data, but the operations > > or behaviour assigned to them. For example, a "date" CBO may have a > > specific data structure to it, but more importantly it will have > > behaviour. One example that comes to mind for the date CBO is the > > "addMonth" operation which I have seen on several versions of CBOs out > > there. From an XML messaging point of view, I could send simply > > <addMonth/> within the ebXML TRP enveloping scheme, and the date > > object (within WHATEVER context it is placed) would be adjusted by one > > month. No "data" is sent at all. This is NOT a virus. > > > > I apologize if the reg-rep document stated what it did, but it has > > complete relevance to reg-rep, as the interactions with reg-rep > > instances will be similar to this form. In our registry information > > model we need a party CBO with the behavior assigned (to identify who > > owns the submitted object, etc.). If CC cannot deliver this to us, > > we'll just have to adopt something from SF Project or other CBO > > initiatives. > > > > Scott > > > > > > > > > > -----Original Message----- > > From: Lisa M. Shreve [mailto:lms@wwnet.com] > > Sent: Monday, September 11, 2000 4:03 PM > > To: Nieman, Scott > > Cc: 'mblantz@LTVSteel.com'; ebxml-stc@lists.ebxml.org > > Subject: Common Business Objects > > > > Scott, > > > > Thank you for distributing the updated r&r document, I'm > > sure Mary Kay is pleased with your prompt response. > > > > Frankly, I am stunned that it still contains references to > > common business objects! We have been discussing this since > > May, and I thought that this had been resolved. Apparently > > not. Let me start with: > > > > > > It is the opinion of the Core Components Project Team, > > which consists of 60 members and is the largest project > > team in ebXML, that CBO's are not what we are > > producing. Core Components, referred sometimes to Smart > > Core Components, take on specific meanings, elements > > and refinements, based on Context [such as industry, > > geographic region, product type, etc.] The sensitivity > > to context makes the Core Components smart. Core > > Components do not have behaviors, which is why these > > are not objects. In the eyes of the business > > community, receiving an object would be equivalent to > > receiving a virus. Obviously, this would not be > > desirable! > > > > > > Core Components are specifically designed to meet the PT's > > cross industry interoperability goals of Electronic > > Commerce. These requirements are driving the need for the > > use of context and extension methodology, combined with the > > core. This maximizes our opportunity for reuse, and > > supports the need for concise and semantically significant > > content. > > > > With us now in the delivery phase, we cannot afford to > > continue to argue the PT's overall approach. We did an hour > > presentation in Brussels, we presented jointly with the BP > > project team at the San Jose closing plenary, we have > > answered this question on numerous occasions. What steps do > > we need to take to bring closure to this issue? > > > > Thank you, > > > > lms > > > > > > > > Nieman, Scott wrote: > > > > > here you go: > > > > > > http://www.e > > > xml.org/project_teams/registry/private/P1Comments.html > > > > > > Scott > > > > > > -----Original Message----- > > > From: mblantz@LTVSteel.com [mailto:mblantz@LTVSteel.com] > > > Sent: Friday, September 08, 2000 1:08 PM > > > To: ebxml-stc@lists.ebxml.org > > > Subject: Re: UDDI, ebXML, and ecoFramework > > > > > > Mike, > > > > > > Much as I would like you to have the last word, I must ask > > > a question. > > > > > > You indicated a knowledge of the R&R that is more than I > > > know. I trust you > > > have found the documentation somewhere. > > > > > > Please share. > > > > > > Mary Kay > > > > > > Mike Rawlins <rawlins@metronet.com> on 09/08/2000 01:37:39 > > > PM > > > > > > Please respond to rawlins@metronet.com > > > > > > To: ebxml-stc <ebxml-stc@lists.ebxml.org> > > > cc: (bcc: Mary K Blantz/CLGO/LTV) > > > Subject: Re: UDDI, ebXML, and ecoFramework > > > > > > Rik, > > > > > > Since only you and I seem to care much about this ;^), and > > > we've both stated > > > our > > > opinions, I don't see much to be gained by continuing this > > > dialogue. > > > However, > > > I'm sure you'll agree with me that there's a big > > > difference between the BP > > > metamodel using parts of the eCo framework, and ebXML > > > adopting it wholesale > > > with > > > all of its interfaces, schemas, and implementation > > > details. Those are > > > beyond > > > the scope of the BP work. They also don't fall within > > > R&R, since R&R is > > > only > > > working on means to host any generic artifact, and not > > > working on the > > > details of > > > the kinds of TP information needed for discovery. The > > > details of trading > > > partner discovery logically fall within the responsibility > > > of the TP team, > > > but > > > that team has not yet even reached a consensus that > > > trading partner > > > discovery is > > > within its scope. In fact, the last time it was discussed > > > the consensus was > > > that discovery was *not* within the team's scope. > > > > > > So, there you have it. You going to give me the last > > > word??? Have a good > > > weekend. > > > > > > Mike > > > > > > rik drummond wrote: > > > > > > > since it specified layer i would say it means uses..... > > > best regards, rik > > > > > > > > -----Original Message----- > > > > From: Mike Rawlins [mailto:rawlins@metronet.com] > > > > Sent: Friday, September 08, 2000 12:07 PM > > > > To: ebxml-stc > > > > Subject: Re: UDDI, ebXML, and ecoFramework > > > > > > > > Thanks, Rik, but there are only two specific references > > > to eCO in the BP > > > > metamodel document v2. > > > > They say: > > > > > > > > 126 -129 > > > > > > > > 2. Markets and Parties > > > > This is the part of the model that allows organizations > > > to register > > > > themselves relative to the markets they perform in and > > > the types of > > > services > > > > they offer. This aligns with the first four of the seven > > > layers of the eCO > > > > framework. > > > > > > > > 679 - 680 "an eCO style self-registration on your own > > > site might be > > > > workable'" > > > > > > > > I assume that the first reference is the most > > > significant. I'm not > > > familiar > > > > enough with eCo or the BP work effort to know whether > > > "aligns" means just > > > > "corresponds to" or "is based on". In either case, I > > > still think that > > > > making a generalization about planning to use eCo is > > > still an > > > overstatement. > > > > > > > > rik drummond wrote: > > > > > > > > > mike the references are in the bp documents.... and > > > were there before we > > > > > read them at the tmwg meeting.... rik > > > > > > > > > > -----Original Message----- > > > > > From: Mike Rawlins [mailto:rawlins@metronet.com] > > > > > Sent: Friday, September 08, 2000 11:02 AM > > > > > To: ebxml-stc > > > > > Subject: re: UDDI, ebXML, and ecoFramework > > > > > > > > > > All, > > > > > > > > > > I appreciate Klaus' prompt action in addressing the > > > issues UDDI raises > > > > > with his note yesterday. However, I think that > > > there's a > > > > > misrepresentation in that our plans for using the eCo > > > Framework were > > > > > stated in a stronger fashion than they actually are. > > > To my knowledge, > > > > > no team has yet developed or approved at the team > > > level even high level, > > > > > informal requirements for trading partner discovery, > > > much less come out > > > > > with a firm position that we plan to use a specific > > > approach such as > > > > > eCo. It is certainly the opinion of several of us > > > that ebXML will end > > > > > up specifying eCo, but giving the impression now that > > > ebXML has already > > > > > made that decision is premature and inaccurate. Such > > > representations > > > > > can only have negative consequences, and I request > > > that Klaus and the > > > > > rest of the Executive Committee be a little more > > > careful in the future > > > > > with their statements about such technical matters. > > > > > > > > > > Regards, > > > > > -- > > > > > Michael C. Rawlins, Rawlins EC Consulting > > > > > http://www.metronet.com/~rawlins/ > > > > > > > > -- > > > > Michael C. Rawlins, Rawlins EC Consulting > > > > http://www.metronet.com/~rawlins/ > > > > > > -- > > > Michael C. Rawlins, Rawlins EC Consulting > > > http://www.metronet.com/~rawlins/ > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC