OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: [regrep] Standards approval process


Duane,

I think it would be better to retain control of the process on our
OASIS side here.

I'd prefer this being sent to them as a status check - rather than an
end product and hand-off.

E.g. "Here's where we are right now.  We are continuing to work
        on this - please provide feedback so we can resolve and
        understand better the needs and goals".

Otherwise I think we will lose track of what really happens
after this and going forward.

Cheers, DW

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
To: "BEDINI Ivan RD-BIZZ-CAE" <ivan.bedini@francetelecom.com>
Cc: <regrep@lists.oasis-open.org>; "Breininger, Kathryn R"
<kathryn.r.breininger@boeing.com>
Sent: Monday, January 17, 2005 4:31 PM
Subject: Re: [regrep] Standards approval process


>
>
> BEDINI Ivan RD-BIZZ-CAE wrote:
>
> >I'm sorry but the mapping is not so simple:
> >
> >
> DN - you are right - very complex.
>
> >the better solution for ASCC and ASBIE is an ebRIM association or an
> >extrinsic object ?
> >
> >
> Could be.  I would assert that nobody knows the requirements since
> nobody knows how big it may eventually scale.
>
> >do we need a dedicated registry object for BCC, BBIE, ASCC, ASBIE
> >properties or an association is enough?
> >
> >
> All tghose things CAN be registry objects.  It is one way of doing
> things and it does have it's merits (simplification, no dependency upon
> registry).  The associations within the registry can represent the
> relationships between the things.
>
> >Business Context will be a registry classification or an extrinsic
> >object ?
> >
> >
> Actually, I think that the context declaration is an intrinsic object
> and it is the least understood of all the mechanisms in CCTS. A
> "context" is made up of 8 (current specifications) separate contexts.
> There are no enumerated lists of values for each single context
> therefore there is no way to guarantee interoperability.  It is also
> possible that contexts may have ranges, multiple applicable values and
> also may need to be subdivided smaller.  The result is approximately 35
> million different context possibilities.  The magnitude of this problem
> and lack of clarity scare me.
>
> >................................................
> >
> >................................................
> >
> >I understand why you tell that the serialization is most important that
> >how we will store that, belive me. but we forgot the CCTS UML schema.
> >My feel is that the serialization of the CCTS is not so simple.
> >
> >
> DN - the first thing to do was to define the requirements for
> serialization.  We did that and it was approved by this TC.
>
> >So we can :
> >
> >1 - give an XML format that answer to all needs or
> >
> >
> DN - IT is a good short term fix but as I said earlier, it does have its
> issues.
>
> >2 - assure that we are able to treat the submitted information
> >
> >
> >in this case if we arrive to define how all the classes are mapped into
> >ebRIM, than we will be able to map every serialization that we provide
> >to CCTS.
> >
> >I think that for CCTS the better approach isn't :
> >"If someone sends me a core component, what will I get?"
> >
> >but :
> >if someone sends me a core component (in XMI, XSD,TBG Excel, OASIS ebXML
> >Registry SCM SC serialization, LomakeFi format, EDIFRANCE BS, ...), am I
> >sure that I will be able to store all information and retrieve that?
> >After we can speak about what serialization is better ...
> >
> >are you agree ?
> >
> >
> Not here.  Before you can store it, you have to be able to read it.
> Therefore, you have to know the serialization format.
>
> ;-)
>
> Duane
>
> -- 
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Chair - OASIS eb SOA TC -
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
> ***********
>
>
> 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/members/leave_workgroup.php.
>
>
>




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