Re: [regrep-cc-review] Kickoff!

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
I may want to store as a UML profiled object. Will you render the ebXML
registry as non-selectible by insisting on XML?
</Quote>

I agree with Mark's statement. We are not insisting on XML, but rather
creating an XML serialization for Core Components. Registry users should
have the opportunity to store Core Components in an XML format or a UML
format (or EDI, for that matter). The UML representations would simply
be registered objects, with a type (using term generically) value of
"UML" assigned to them. Similarly, XML representations would have a type
value of "XML". This could be done through Slots, or through a
classification scheme of Core Component representation types (and a
classification of each Core Component according to that scheme).

Let's ensure that we include all of these concepts in our final
documentation.

Thanks,
Joe

"CRAWFORD, Mark" wrote:
> 
> > 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.
> 
> Agree.
> >
> > 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.
> 
> Mark
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard