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: [regrep] 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


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


Powered by eList eXpress LLC