Re: [regrep] Summary: Implementing CCTS in Registry

[Chiusano Joseph <chiusano_joseph@bah.com>]

Thanks Farruhk.  I will let David (Webber) respond on CAM - please see
comment below:

<Excerpt>
>- Serialization format
>
above is out of scope (this is not a reflection on its merits). It is in 
the scope of CCTS team. Registry will handle whatever Seria;ization 
fromat they choose with more out-of-box features in case it is an XML 
format.
</Excerpt>

The CCTS Team definitely considers the definition of serialization
formats for Core Components outside of their purview - they are looking
to others to do so (if they did so, it would mean defining
serializations not only for XML, but also for X12 EDI, EDIFACT MIG's,
and perhaps other formats as well).  From p.10 of CC spec:

"The Core Components approach described in this document is more
flexible than current standards in this area because the semantic
standardisation is done in a syntax-neutral fashion."

The CC spec also refers to the creation of the syntax-specific
representations of Core Components and their associated entities as part
of the steps for "Overall Discovery and Document Design" as something
that is outside of the CC spec - from p.24:

"Step 5: Create MIG, XML schema, etc. – The resulting semantic model
(the set of Business Information Entities) is manually or
programmatically rendered into a syntax-specific message description.
The resulting MIG, XML schema or other syntax specific message
description is submitted to the registry where it is associated with the
Business Information Entities it represents."

Farrukh Najmi wrote:
> 
> Chiusano Joseph wrote:
> 
> ><Excerpt>
> >
> >
> >>However, not every thing captured in that summary necessarily belongs in
> >>ebXML Registry TC. I propose we focus our discussion first by defining
> >>what is *IN* vs *OUT* of scope for the CC registration/discovery
> >>discussion.
> >>
> >>
> ></Excerpt>
> >
> >Thanks, Farrukh.  I'll take that one step further, in the interest of
> >keeping the discussion focused.  Here is a list of (what I believe is)
> >"everything captured in the summary":
> >
> Here is my opinion on in/out of scope:
> 
> >
> >- Registry metadata representations
> >
> above is in scope
> 
> >- Defined binding to registry
> >
> above is in scope
> 
> >- CAM
> >
> above is out of scope (this is not a reflection on its merits). It is in
> the scope of CAM TC or Content Assembly tools.
> 
> >- Serialization format
> >
> above is out of scope (this is not a reflection on its merits). It is in
> the scope of CCTS team. Registry will handle whatever Seria;ization
> fromat they choose with more out-of-box features in case it is an XML
> format.
> 
> >
> >Would you be willing to elaborate more on what you believe might be out
> >of scope?
> >
> Please state any differences of opinion from above scope boundaries. Thanks.
> 
> >
> >- Joe
> >
> >Farrukh Najmi wrote:
> >
> >
> >>Rather than getting into a debate here about CAM, I believe that Content
> >>Assembly is outside the scope of ebXML Registry work and is the purview
> >>of content assembly tools. The only context I can think of for content
> >>assembly being discussed in ebXMl Registry TC is if there are any
> >>registry requirements necessary to support content assembly.
> >>
> >>Joe's summary is an great attempt at capturing the key points of view.
> >>However, not every thing captured in that summary necessarily belongs in
> >>ebXML Registry TC. I propose we focus our discussion first by defining
> >>what is *IN* vs *OUT* of scope for the CC registration/discovery
> >>discussion. Right now I feel we are meandering a bit too wide.
> >>
> >>Am I off base here?
> >>
> >>--
> >>Regards,
> >>Farrukh
> >>
> >>David RR Webber - XML ebusiness wrote:
> >>
> >>
> >>
> >>>Dave,
> >>>
> >>>Note - UMM is nothing to do with CAM - since UMM is nothing
> >>>to do with XML - rather stating the obvious - like saying
> >>>fertilizer has nothing to do with Origami - but paper is made
> >>>
> >>>
> >>>from wood.
> >>
> >>
> >>>Anyway - since UMM has nothing to do with the topic of
> >>>CC serialization - I'm at a loss to understand why you
> >>>said any of this at all.
> >>>
> >>>CAM is about content assembly - and therefore works
> >>>with Registry, Webservices, EDI, OAG BODs,
> >>>RosettaNet, UBL et al - and can be used with ebXML as
> >>>well.
> >>>
> >>>The fact that we can use it for CC serialization
> >>>is perfectly acceptable - just like using XPath,
> >>>XQuery or any other XML technology component.
> >>>
> >>>Cheers, DW.
> >>>====================================================
> >>>Message text written by Dave Welsh
> >>>
> >>>
> >>>
> >>>
> >>>>Rest looks fine except for the CAM stuff, which
> >>>>
> >>>>
> >>>>
> >>>>
> >>>is / has not been part of the ebXML work nor is it in line with the
> >>>UN/CEFACT UMM approach on that subject..<
> >>>
> >>>
> >>>----------------------------------------------------------------
> >>>To subscribe or unsubscribe from this elist use the subscription
> >>>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>>
> >>>
> >>>
> >>>
> >>
> 
> --
> Regards,
> Farrukh
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano