[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)
David: What is the issue? (not sure if I understand). We are using the registry uuid in conjunction with the registry accessor information to make sure a person can always get back to the exact artifact the xml was based on. It can resolve at the generate time or subsequently. The uuid is the same as a uid to me since if you use either with a uri t specify the exact domain (registry) that the artifact must be unique within, there is no problem (assuming that a DCE 128 bit algorythm for generating a UUID as per the regrep specs will not likely generate two identical uuid's by co-incidence). Duane David RR Webber wrote: >Duane, > >Do NOT use the UUID - use a UID instead - and resolve at generate time. That >way you always get the correct version. CAM approach with <ContentReference> >is designed to avoid this issue. > >DW. > >Quoting Duane Nickull <duane@yellowdragonsoft.com>: > > > >>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. > > >> >> > > >http://drrw.net > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]