Re: [regrep-cc-review] Kickoff!

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

<Quote1>
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. 
</Quote1>

I was not looking at XML serialization to perform that role, but rather
to have these "other format" objects stored in the registry along with
the equivalent XML format (for example, 2 representations of an object -
one XML, the other UML). Then, these 2 representations would be
associated using the registry association mechanism.

Please tell me if I am missing something.

<Quote2>
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. 
</Quote2>

Please see response above.

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

Absolutely!

<Quote4>
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. 
</Quote4>

Will that cover all of the requirements in CCTS Section 7? Perhaps (but
I highly doubt it!). Our mission is to cover the requirements in CCTS
Section 7.

<Quote5>
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.
</Quote5>

They (the CCTS) simply want us to verify CCTS Section 7. Our
requirements are spelled out in the CCTS spec Section 7, and we are free
to engineer a solution - that is our mission here.

Joe
David RR Webber - XML ebusiness wrote:
> 
> Joe,
> 
> I say we get these upfront as requirements - not the other way
> around.
> 
> There's too much potential for confusion here.  We need to
> have this exact - and especially agree on terminology and
> intent.
> 
> 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.
> 
> DW.
> =====================================================
> 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
> documentation.
> <
> 
> 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