Re: [regrep] Issue with UUID's for Core Components and BIE's

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

Joe,

Yeah - I know that - but it gets pasted as ASCII into the XML - so
your 16 byte internal representation gets bloated to a lot more in
actual use everywhere.

Anyway - the real point is - I do not supposed BAH will have
too many clients lining up to manage their BIEs using codes like

  "urn:uuid:4a593056-3509-0766-2e7b-4e154030423f"
  "urn:uuid:4a593056-3509-0766-1e7b-4e154030423f"
  "urn:uuid:4a593056-3609-0766-2e7b-4e154030423f"
  "urn:uuid:4a593056-3509-0766-2e7b-4e154030423e"

instead of

 "USPS020015"
 "USPS020021"
 "USPS020315"
 "USPS020013"

etc.

Cheers, DW.

----- Original Message ----- 
From: "Chiusano Joseph" <chiusano_joseph@bah.com>
To: "David RR Webber" <david@drrw.info>; "Farrukh Najmi"
<Farrukh.Najmi@Sun.COM>; "Duane Nickull" <dnickull@adobe.com>;
<regrep@lists.oasis-open.org>
Sent: Friday, April 09, 2004 11:16 AM
Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's


> David RR Webber wrote:
> >
> > Farrukh,
> >
> > I know we've had this disagreement before.  I'm not
> > arguing with you from the registry engineering PoV -
> > I understand why the registry itself needs these UUID
> > keys internally.
> >
> > It's the way they get used externally that frankly does
> > not meet the business use case of things like CCTS,
> > CPA, BPSS, CAM and more.
> >
> > Your point about the 16 bytes reminded me of another
> > big issue -using these UUIDs you also need to avoid
> > embedding the URL for the registry too - making this
> > even more ugly (what if you need to relocate your registry
> > to a new server?).
> >
> > Here's an example from Duanes code - I count a lot
> > more than 16 bytes here:
> >
> > "urn:uuid:4a593056-3509-0766-2e7b-4e154030423f"
>
> Going back to my bits-and-bytes OS roots for a second (I used to love
> reading binary and hex):
>
> This *is* actually exactly 16 bytes. Each character (minus the dashes)
> is a hex value representing 4 bits - from 0 (0000) to f (1111), or - in
> base 10 - from 0 to 15. I've reproduced it below, with each pair of
> characters representing a single byte. The "|"'s delineate sets of 4
> bytes, for a total of 16 bytes:
>
> "4a 59 30 56 | 35 09 07 66 | 2e 7b 4e 15 | 40 30 42 3f"
>
> Don't worry, I won't go down the road of telling you what exact number
> this is...;)
>
> Joe
> > By comparison the UID system is available to
> > prevent having to do all this syntax mucky-muck.
> > Using the character code prefix - the Registry is
> > referenced via an ALIAS and therefore the
> > physical address location can be easily and
> > quickly changed by assoicating the alias to the
> > registry address - and the UID values themselves
> > can be assigned simply and easily with a code
> > that makes sense to the
> > business functional users, and can be versioned
> > and sub-versioned directly.
> >
> > Example UID:   USPS020015
> >
> > United States Postal Service BIE - in the 20000
> > series - all of which relate to Mailing Address
> > structure elements, and so on.
> >
> > And then UID:  USPS020015:01:03
> >
> > is version 01, sub-version 03 - of that same BIE
> > structure - where say the country codes have been
> > updated for the new members of the EU countries.
> >
> > This is why we put the EXTERNAL ID functionality
> > in the Registry RIM - and that is why we should be
> > recommending people use it for CCTS and other
> > content referencing needs.   It provides domain-centric
> > labelling of content and that is a very good thing that
> > we should be advertizing as an excellent feature.
> >
> > The UUID takes us backwards - that's how we
> > ended up with EDI in the firstplace - completely
> > dictated by machine level technology devices and
> > mechanisms - instead of business use
> > case needs.  The whole point of CCTS is to move
> > beyond machine level stuff to a higher business
> > neutral system.  Using UUIDs is like thorns on a rose
> > IMHO here.
> >
> > Thanks, DW
> >
> > ----- Original Message -----
> > From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
> > To: "David RR Webber" <david@drrw.info>
> > Cc: "Duane Nickull" <dnickull@adobe.com>; "UN/CEFACT Core Component WG"
> > <uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org>
> > Sent: Friday, April 09, 2004 9:13 AM
> > Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's
> >
> > > David RR Webber wrote:
> > >
> > > >I hope this is the last and final time we have to have this
discussion
> > > >around erroneous use of UUID values as external linkage identifiers
> > > >to registry content - they are for INTERNAL use only - and should
> > > >be used for such programmatic pointer uses only within the API
> > > >to registry.
> > > >
> > > I respectfully disagree. The UUID based URN (urn:uuid:....) should be
> > > used to
> > > uniquely reference an object internally or externally. I agree that
for
> > > human
> > > consumption you may want some ExternalIdentifier such as a human
> > > friendly URN.
> > > But strictly for reference purposes (internal or external to registry)
I
> > > still
> > > suggest using UUID based URNs.
> > >
> > > >I understand the tempatation to make your Java code
> > > >easier to write by burying all these UUIDs into the access method
> > > >to the registry - as a quick kludge - but you have to remember the
> > > >central tenet of computer software - its supposed to make work
> > > >easier for human operators - not harder!   Not to mention the
> > > >ludicrous overhead associated with a 128 byte boat anchor to
> > > >what is often less than 30 bytes of information....
> > > >
> > > >
> > > Oops, I think you meant to say a "16 byte boat anchor" not a "128 byte
> > > boat anchor".
> > > Which is definitely less than "30 bytes of information".
> > >
> > > To be clear... A UUID is 16 bytes not 128 bytes.
> > >
> > > --
> > > 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.
> > >
> > >
> >
> > 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.
>
> -- 
> Kind Regards,
> Joseph Chiusano
> Associate
> Booz | Allen | Hamilton
>