Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site update request)

["David RR Webber" <david@drrw.info>]

Duane,

I thought you had posted a note about versioning and not being able to
track that.  Since a UID can be versioned, while a UUID cannot - if
you need to support versioning - then you will need to define the
content linkages via the UID referencing.

Appears you are not supporting versioning - just static revisions...

Thanks, DW.
----- Original Message ----- 
From: "Duane Nickull" <duane@yellowdragonsoft.com>
To: "David RR Webber" <david@drrw.info>
Cc: "Chiusano Joseph" <chiusano_joseph@bah.com>; "Farrukh Najmi"
<farrukh.najmi@sun.com>; <Kathryn.r.Breininger@boeing.com>;
<regrep@lists.oasis-open.org>
Sent: Thursday, September 25, 2003 9:40 PM
Subject: Re: [regrep] Re: Republica Case Study (Was: Re: [regrep] Web Site
update 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
> >
> >
>
>
>
> 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.
>
>