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 say we get these upfront as requirements - not the other way

There's too much potential for confusion here.  We need to
have this exact - and especially agree on terminology and

We need the XML serialization.   The fact that XML serialization
can point to other objects in other formats - such as UML 
modelling tool binaries, Word docs, HTML and more, is
a registry functionality.   XML is the baseline format - we 
provide that.    If other people want to figure out how to 
store UML or EDI natively - that's their business not ours - 
and I'd say that is out-of-scope for the current RIM.  

BTW - notice there is strictly not an "UML representation".
XMI is an XML syntax for exchange UML models as vector
sets - and UML modelling tools have ability to save binaries
of their models.  We can store either as objects only, no ability
to search or interprete semantics inside them.  That's why
we need the XML serialization to provide that.

More especially - we need a simple and clear serialization,
that people can understand and can populate readily.   

One of the biggest issues is that people simply do not understand
what CCTS is - how to use it - and how it relates to their 
own world.   Obviously now we have the CCTS tutorial
to help guide that conceptual layer - but beyond that there
is no way to relate that to the logical and physical layers
except through applying the XML serialization.

We could of course build that very simple box for CCTS based
on their columns in their spreadsheet, I recall they have about
6 columns.  That will take about 30 minutes to do in XML. If they
want more than that - then we need to be able to clearly
set out the requirements and then be given freedom to 
engineer a solution.

Message text written by "Chiusano Joseph"
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

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