Re: [regrep-cc-review] Re: Methodology - OWL

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

Thanks for your thoughts Steve. Please see comments inline marked with
<JMC>.

Steve Capell wrote:
> 
> Hello all,
> 
> I am only an observer but I would like to support Duane's position that a
> standard core component serialisation format is a valid and important task
> for this subcommittee.  However I'm not sure I agree that only one
> interfchange format is relevant or that it needs to be too tightly coupled
> to the storage model so I'm going to expose my ignorance and ask a few
> questions:
> 
> 1       The reason to have a serialisation format is for interoperability between
> "consumers" of core component data right?  

<JMC>
I concur.
</JMC>

I expect that the most likely
> tool that will interface with a core component repository is a UML modelling
> tool.  Accordingly the repository content needs to be understood by a UML
> tool.  Despite it's imperfections, XMI is the most widespread fromat for
> interchange of models so a core component repository probebly ought to
> support delivery of core components in XMI format. 

<JMC>
This point should definitely be considered if the Registry TC begins
work on defining a serialization format for CC's. I suspect we may also
want to transfer CCs and BIEs "themselves" (i.e. with their data)
between systems, not just their metadata.
</JMC>

As UML2 comes into play
> and OMG's MOF work becomes more widely supported, I would have thought that
> model interchange formats will become more important and more consistent.
> 
> 2       Not all developers of e-business standards like to use a model based
> approach.  In fact many would jump straight into the XML.  The obvious
> problem with that is that there are a host of different ways that the same
> semantic content can be represented in XML syntax.  Nevertheless wouldn't it
> be nice if I could just download the re-usable components from a repository
> into my XML authoring tool?  Better still if the repository provided some
> consistent naming & design rules for the XML generation (such as the good
> work done by the UBL group and currently being adopted/modified by
> UN/CEFACT).

<JMC>
I concur with all of #2.
</JMC> 

> 3       Then again this group might define a standard serialisation format in XML
> or some other syntax that is a little different to either of the above.
> Probably for good reason - to address the limitations of XMI and to contain
> the complete CCTS model data (which UBL serialisation would not do).  So now
> there is a third (and formal standard) way of representing the core
> component.

<JMC>
I believe that with the amount of analysis that this group (in various
forms) has done on CCTS over the past several years, that we have an
excellent handle on both the strengths and shortcomings of the spec, as
well as how to work around those shortcomings. Therefore I feel that the
Registry TC is in an excellent position to consider defining an XML
serialziation for CCs, perhaps even more so than other groups (emphasis
on perhaps).
</JMC> 

> 4       Unfortunately I dont have enough knowledge on OWL/RDF to comment about
> it's use for core component serialisation but it is at least the foundation
> for another option...
> 
> I guess what I am saying is that if I were trying to build a commercial core
> component repository that was useful to todays community, I think I would
> offer a few options for the syntax that the same core component can be
> delivered / published.  "Do you want this standard address structure as an
> XMI file for your modelling tool or as a UBL NDR compliant XSD for your XML
> authoring tool or in the standard OASIS representation?"

<JMC>
I see UBL as separate from the other 2 possibilities you mention above,
as UBL (in my view) is (primarily) an XML vocabulary that represents
business transactions. The XMI and standard OASIS representations would
be on a different "level" - that is, for exchange of "CC metadata" and
"CC metadata with data" (need better terms) between systems for more
"backend" purposes rather than pure information exchange.
</JMC>
 
> All these formats would be delivered from the same storage model so that
> storage model needs to be a superset of the requirements imposed by the
> various likely interchange formats.  So I think that both the current
> storage model work and interchange format work need to progress in parallel.
> I also think that work on serialisation needs to recognise the practical
> realities of the way in which core components will be used.
> 
> For example, can we consider that:
> 1       Replication of a core component between repositories

<JMC>
Absolutely - this is covered by the ebXML Registry Cooperating
Registries feature, as CCs and BIEs will be RegistryObjects.
</JMC>

> 2       Publishing of new core componets (eg registering a new ABIE as a context
> driven variant of an ACC)

<JMC>
Absolutely - this will be covered in the TN that I am writing on behalf
of our efforts here.
</JMC>

> 3       Querying the library of core components for an existing component to use
> in my message development

<JMC>
Also covered in TN.
</JMC>

> all require the same data in the interchange?  

<JMC>
They all require the same CC/BIE metadata (if that's what you are
referring to).
</JMC>

Wouldn't there be lifecycle
> and ownership data in the first one that is not needed in the third one.  

<JMC>
Yes - also covered in the Cooperating Registries feature.
</JMC>

So
> the first one might NEED the "standard" interchange format whilst the last
> one would better use a UBL (or UN/CEFACT) compliant XSD?

<JMC>
I believe that they would both need the "standard" interchange format. I
envision UBL as coming into the picture after the various CC-to-BIE
contextualization process takes place, and the BIEs are assembled to
create the various aggregates. This process would result in a UBL
schema. So the things we are primarily addressing here regarding are -
as I see it - "pre-UBL" steps.
</JMC>
 
> Just some thoughts... sorry for the rambling...

<JMC>
Thanks for your excellent thoughts Steve!
</JMC>
 
Joe

> regards,
> 
> Steve Capell
> RedWahoo
> Sydney, Australia
> Tel : +61 410 437854
> 
> This email message and any accompanying attachments may contain information
> that is confidential and is subject to legal privilege. If you are not the
> intended recipient, do not read, use, disseminate, distribute or copy this
> message or attachments. If you have received this message in error, please
> notify the sender immediately, and delete this message. Any views expressed
> in this message are those of the individual sender, except where the sender
> expressly, and with authority, states them to be the views of Red Wahoo Pty.
> Ltd.
> 
> Before opening any attachments, please check them for viruses and defects.
> We do not accept any liability for loss or damage which may arise from your
> receipt of this e-mail.
> 
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Wednesday, 14 January 2004 6:47 AM
> To: carlmattocks@checkmi.com
> Cc: CCRev
> Subject: Re: [regrep-cc-review] Re: Methodology - OWL
> 
> All:
> 
> I would propose that we use a RUP/UMM type methodological approach to
> our work in this area.
> 
> 1. gather stakeholder requirements, technical requirements of what is
> needed in the Serialization.
> 
> 2. define the serialization first.
> 
> 3. work backwards based on the serialization to determine what must be
> present in the storage format.  IMO - the serialization requirements
> will create dependencies on the storage format.
> 
> To me,  this is the correct and logical way to approach the problem.  I
> hereby volunteer to take a stab at the first draft of #1 above
> (requirements for the serialization).
> 
> Duane Nickull
> 
> --
> Senior Standards Strategist
> Adobe Systems, Inc.
> http://www.adobe.com
> 
> To unsubscribe from this mailing list (and be removed from the roster of the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_
> workgroup.php.
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.