[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's
David RR Webber wrote: >Farrukh, > >I still think its better to upgrade the External ID. > >And less confusing -if you have two things doing >related and overlapping things - which do people >pick - or do they put the same value in both >places - probably - and therefore its a clue >it should be just one field. > > I agree that similar but different things are confusing and bad. I have found that ExternalIdentifiers are the least used feature of RIM. I personally do not like them the way they are. I think it would have been better to have their type be Slot. In other words a RegistryObject has an externalIdentifiers attribute that is a Collection of Slots and also a Slots attribute that is a Collection of Slots. The first has a specific meaning (external identiofiers) while the later could have any meaning wahtsoever. I absolutely do not like the fact that to have a simple value such as a LID you need to define a LID ClassificationScheme. Also ExternalIdentifier is an extensibility mechanism similar to Slots that can be just about anything. While the LID is a much tighter first class part of the model similar to id. It is just so fundemental and basic taht we want it to be reachable by the most direct path. >Not sure this should be mandatory - blanks >should be allowed - since people may insert >content that does not need a LID - or may >choose to assign one at some later point >in the process. > > According to the proposal a LID is required but if the client does not provide it the registry generates one. Things like IDs logical or otherwise should not be late bound in my opinion. There are too many issues that crop up when you do that. >I'm completely baffled as to why you think a >separate LID field is more efficient - queries >should be just as fast either way. > > Because it is part of the object and does not require a join of two objects to assemble it (say in a relational model). It is fetched in the same access as teh rest of the object. That said I am not a big fanb of premature optimizations. >Also - surely everything inserted into the registry >requires a classification so - I'm not seeing any >difference here? > > Actually my experience is that most things in the registry are not classified. >Thanks, DW. > >----- Original Message ----- >From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> >To: "David RR Webber" <david@drrw.info> >Cc: <regrep@lists.oasis-open.org> >Sent: Friday, April 09, 2004 3:56 PM >Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's > > > > >>David RR Webber wrote: >> >> >> >>>Farrukh, >>> >>>Why not overlay the LID functionality on the External ID? >>> >>>No need to change the RIM then - and this is in any case >>>the behaviour the External ID was intending to have all >>>along ; -) >>> >>> >>> >>> >>Good observation David. >> >>I considered that very point but decided against it because every object >>needs to have a LID (like an id) and given >>that ExternalId requires a ClassificationScheme it seemed better for >>queries to >>introduce a new attribute. It would also be more efficient for storage >>and retrieval. >> >> >> >>>Thanks, DW. >>> >>>----- Original Message ----- > >>> >>> >>> >>> >>>>Please see the latest Versioning proposal posted after Nikola and I >>>>worked on the last one. The Logical ID (LID) addresses the >>>>need for a human friendly ID. Check it out at: >>>> >>>> >>>> >>>> >>>> >>>> >>http://www.oasis-open.org/apps/org/workgroup/regrep/download.php/6326/Versi >> >> >onControlProposal-03.doc > > >>> >>> >>>>-- >>>>Regards, >>>>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. > > >>> >>> >>>> >>>> >>> >>> >>> >>-- >>Regards, >>Farrukh >> >> >> >> >> > > > -- Regards, Farrukh
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]