[regrep] Re: Core Components Specifications

[Chaemee Kim <cmkim@ktnet.com>]

FYI,

Plz, visit ebXMLRegistry 1.0 on Web Browser developed by KTNET.

http://www.gxmlhub.com/english/index.htm
Click "ebXML Service".

Any users can discover any contents in ebXML Registry and also core components can be submitted in ebXML Registry. Just try it and make clear sentence on specification!

Good Luck!

----- Original Message ----- 
From: "David RR Webber - XMLGlobal" <Gnosis_@compuserve.com>
To: "Hermes Hartmut" <Hartmut.Hermes@MCH11.siemens.de>; "OASIS Registry List" <regrep@lists.oasis-open.org>
Cc: "'Ebtwg-Ccs (list)'" <ebtwg-ccs@lists.ebtwg.org>; "'eBTWG (list)'" <ebtwg@lists.ebtwg.org>
Sent: Sunday, January 27, 2002 5:38 AM
Subject: FW: Core Components Specifications


> Hermes,
> 
> Here is my comment.
> 
> Why do we still have this section in there?   1263 thru to 1279.
> 
> This is complete eye wash!
> 
> Who said that SME's would not be able to access an ebXML Registry??
> That is complete nonsense.  The Registry team is working hard on making
> an open specification - and vendors are implementing user interfaces 
> thru Web Browsers that clearly enable an Excite or Yahoo style free access
> model, in addition to librarian and organization access modes, that enable
> SME participation and access.
> 
> Further more it is complete nonsense to state that the ebXML Architecture
> concept calls for a repository held in UML format.  It must be clearly
> stated that
> UML is NOT required (what SME understands or owns UML tools, hello!!??!!).
> 
> Frankly I'm disappointed that this section - after specific attention had
> already been
> called to this on the PREVIOUS draft, has not been amended.   Can we please
> take out this section.  It clearly is not in alignment with the spirit and
> intent of the
> ebXML requirements vision.
> 
> We've worked very hard to this point to provide neutral XML based formats
> and
> mechanisms to enable the high level mechanisms and functionality that we
> see is essential for the processing of ebXML.  
> 
> If people choose to use UML to augment that - and they believe there is 
> business value in that - all well and good for them.  We have always been
> very clear
> however that mandating use of UML is not in keeping with the majority of
> the
> ebXML community's needs.  There are 3 models here, small, broad and large.
> Only in the large model does UML provide extended value (ie to large
> corporations),
> while in the small and broad it is clearly optional.
> 
> Also - when I look at Table 6-5, this is only a partial representation at
> some high
> level of abstraction.  The CCR/CRI work provides complete and extended 
> abilities to represent not only all this information, but much more
> accurate and
> complete detail.  Remember, the computers we use today require exact and
> explicit instructions.  Therefore programmers ultimately require exact
> representations in order to produce the needed business behaviours we 
> desire.  This ultimately requires the level of detail that the CCR/CRI work
> is
> providing, and using plain simple neutral wellformed XML content mechanisms
> that we can guarantee will work across platform and language and parser
> implementations.
> 
> What's more the CCR/CRI XML has content in it that is compatible with the
> Registry
> information model, and how content is stored, retrieved, versioned and
> owned 
> within a Registry.  Again, this is not manifested in UML nor in Table 5-6.
> 
> If we must keep 6.1.4 then the first sentence is all that needs to be
> stated.  And then
> we might also choose to mention the CCR work and the Registry work.
> 
> 6.1.4 Catalogue of Core Components 1263
> As originally articulated in the ebXML architecture concept and perpetuated
> in the 
> developing UN/CEFACT architecture concept, all Core Components will be
> recorded 
> in an ebXML compliant registry and stored in a related repository.   The
> Core Components
> Realization work is deriving the means to store such content into the ebXML
> Registry, and
> the ebXML Registry specifications provide the Information Model for
> interactions with this
> content - (please see those applicable specifications for extended
> implementation details).
> 
> DW.
> ===========================================================================
> 6.1.4 Catalogue of Core Components 1263
> As originally articulated in the ebXML architecture concept and perpetuated
> in the 1264
> developing UN/CEFACT architecture concept, all Core Components will be
> recorded 1265
> in an ebXML compliant registry and stored in a related repository. However,
> small 1266
> and medium enterprise (SME) organisations may not be able to readily access
> such 1267
> architecture. As such, it is important that the full range of UN/CEFACT
> Core 1268
> Components be published in a freely available catalogue. This catalogue
> must convey 1269
> the full details of each Core Component consistent with how those
> components are 1270
> stored as UML objects in the repository. Table 6-5 identifies a proper
> format for the 1271
> catalogue and contains representative entries from the existing UN/CEFACT
> Core 1272
> Components Catalogue. 1273
> Component Library will consist of the following parts: 1275
> .Core Component Types 1276
> .Catalogue of Aggregate Business Information Entities 1279
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebtwg.org/ob/adm.pl>
>