Subject: Re: [regrep-cc-review] Kickoff!
<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:firstname.lastname@example.org title:Senior Consultant fn:Joseph M. Chiusano end:vcard