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 <>:
>
>
>
>>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
>
>
