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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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

Subject: RE: [regrep-cc-review] Kickoff!

> I think if we focus narrowly on their spec', and do not take a
> broader view initially - then we will constrain ourselves
> artifically.

Seems to me that the narrow focus is the charter of this effort
> Particularly - we need to realize that we are infact building the
> implementation layer for their conceptual layer.  So very little
> in their spec' speaks to implementation mechanics - since they
> are focused on behaviours. 
right.  And the larger picture is really a function of the as yet to be established ebXML Architecture Team - not the registry team.

 >In particular legacy migration of existing vocabularies is an area that I see we have where 
> thru providing better mechanisms at the implementation layer
> we can facilitate adoption of our CCR/S specification.  Notice 
> this is separate and distinct from promoting adoption of CCTS.

> 1) providing XML constructs for the implementation of 
>     ebusiness vocabularies as physical nouns, and aggregates
>     while enabling the deriving of conceptual core components
>     and their crosswalks to the physical entities.

Entirely out of scope.  This is a function of the various business vocabularies themselves.  One reason why you should focus on core components as profiled objects, and not part of a larger XML expression.  Leave that to the individual implementers.
> 2) Supporting rendering implementation layer semantics
>      with physical typing support and validation semantics for the 
>      business logical needs.

Out of scope.
> 3) Providing classification and ontology support and 
>      conceptual typing for the design and modelling needs.

A registry function, not CCTS directly related.
> 4) Providing interfacing to content assembly mechanisms
>      using XML, and support for migrating legacy 
>      non-XML formats.

Why XML?  Where in the ebXML requirements does it say that everything must be in XML?  I may want to store as a UML profiled object.  Will you render the ebXML registry as non-selectible by insisting on XML?
> 5) Providing search and discover support for tools that 
>      support enduser access to a vocabulary, or across
>      vocabularies.

> 6) Enabling industries to share common vocabularies and
>      develop better alignment of semantics for shared 
>      meanings across industries.

The purpose of the CCTS and the harmonization effort that UN/CEFACT is putting in place.


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