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] Re: Republica Case Study (Was: Re: [regrep] Web Siteupdate request)


Thanks Duane. From a Core Components perspective, we are representing
the major entities (BCC, ACC, BIE, etc.) as ExtrinsicObjects in the
registry. So they "inherit" all of those attributes/features of
ExtrinsicObjects, plus the attributes required as part of our Technical
Note. So if I understand you correctly, for our purposes a data element
would equate to a Core Component entity (BCC, ACC, BIE, etc.). So these
issues would be issues for the registry in general.

Joe

Duane Nickull wrote:
> 
> The work we are currently doing also will likely impact CCRIM et al.
> 
> Some issues:
> 
> A data element in a dictionary has an identifier that uniquely
> identifies it within the domain in which is was created.  The RIM UUID
> would duplicate this identifier and supercede it by being a truly
> universally unique ID.  How to store the Data element in a way that when
> it is serialized, it takes it's UUID from the RIM instance and is
> serialized into the format of the data element (in our case xml)???
> 
> A data element asserts it has a certain status bestowed upon it by the
> [Responsible ORganization].  That needs to be ina serialization of the
> data element but cannot conflict with the RIM instance data that
> duplicates its' status.  How to keep these in alignment?
> 
> A lot more where that came from.
> 
> Duane
> 
> Chiusano Joseph wrote:
> 
> ><Quote>
> >Maybe all that is needed is a statement in the paper that states that
> >this work pre-dates CCRIM and will be suprceded by it.
> ></Quote>
> >
> >I think that would be great - thanks Farrukh. I would be fine if it
> >simply states that:
> >
> >(a) It pre-dates CCRIM, and
> >
> >(b) The approaches defined in the paper are not necessarily in line with
> >those to be specified in the forthcoming OASIS/Registry TC Core
> >Components Technical Note
> >
> >I don't think it's necessary to say that it will be superceded by it. I
> >agree that we need to recognize Diego's work, but we also need to
> >recognize the work of the other members of the CC Review team as well by
> >ensuring that there is no confusion as to the recommendations coming fom
> >the team.
> >
> >Thanks,
> >Joe
> >
> >Farrukh Najmi wrote:
> >
> >
> >>(Changed subject per focus of thread)
> >>
> >>Chiusano Joseph wrote:
> >>
> >>
> >>
> >>>I have the following concerns with posting the Case Study paper on our
> >>>site:
> >>>
> >>>(1) The paper is not an OASIS product, yet it uses the OASIS and ebXML
> >>>logos and format. It is also listed as being copyright OASIS, which is
> >>>incorrect (at an extreme, it can be considered fraud - not accusing
> >>>anyone of that though).
> >>>
> >>>
> >>>
> >>Whatever procedural concerns we may find with Diego's paper should not
> >>in any way take away from the fact that the paper  is a valuable asset
> >>as a case study in applying an ebXML Registry. I would like to
> >>congratulate Diego publicly for the good work represented by his paper
> >>and for his willingness to share it.
> >>
> >>
> >>
> >>>(2) The paper describes approaches to implementation of Core Components
> >>>in ebXML registry that are not necessarily in line with the approaches
> >>>that we will be proposing as part of the Technical Note (in fact I can
> >>>tell you that there are contridictions).
> >>>
> >>>
> >>>
> >>The paper's work pre-dates the creation of the CCRIM sub-team. Naturally
> >>its approach will not be in line with CCRIM. However, as a member if the
> >>CCRIM team my recollection is that we leaned heavily on Diego's past
> >>work and experience (described in this paper). I can also safely say
> >>that Diego was one of the most active and enthusiastic contributors to
> >>the CCRIM work (thanks Diego).
> >>
> >>Maybe all that is needed is a statement in the paper that states that
> >>this work pre-dates CCRIM and will be suprceded by it.
> >>
> >>
> >>
> >>>As Chair of the Core Components
> >>>Review Subcommittee, I request that this paper not be listed on our
> >>>site.
> >>>
> >>>
> >>>
> >>>
> >>How about that we make contructive feedback on this new thread to Diego
> >>on what he needs to do minimally in order for us to display the paper
> >>under a new case studies area on our web page.
> >>
> >>We need case studies like this badly, so people can see how our work is
> >>being applied to solve important problems in important places.
> >>
> >>--
> >>Farrukh
> >>
> >>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.
> >>
> 
> 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.
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


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