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

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

Matt,

Once again I have to reinforce my point - you are talking about
middleware programming techniques - and I am not trying to
change those - but we simply cannot have a situation where
the middleware is dictating the business needs and user
mechanisms.   Sure it would be easier if all banking
statements were written in reverse polish notation - I just
don't think many bankers would buy that software
solution off you however.

The bottom line is - people need simple mechanisms - and
the proven fact is they use reference codes to identify content
of all kinds.  Computers should serve people - not the other
way around.

Take for instance your statement:
> A ID mechanism that embeds some prefix in it is a hokey solution, and its
error
> prone unless each organization manages their namespace carefully.
>
> One idea is to embed some more info in the urn, and use a DNS driven
> approach for resolving an extended urn string to a registry object
download
> URL.

So a prefix is hokey - but embedding a bunch of techno-goup is much
better!?!
Sorry - this dog does not hunt in my book.

The real answer is to separate the two mechanisms - not mush them together.
The prefix mechanism I referenced in the UID is absolutely NOT there to
provide assess path information - its solely a visual cue to the human.

Here's an example of using a referencing system that does not rely on
mushing information into a URN - and supports *any* access system - not
just DNS based - so you can use SQL stored procedures, OS file system,
RPCs, ebMS, whatever - to implement your content accessing - so you
can have a reference to something like "0021-BeingTypeIdentfier.xml"
as in the example below -

(personally I would prefer "CCTS000021"  here - but the intent is to
 show the flexiblity and means to accommodate "any* deployment system,
 and actually there's nothing to stop you using more than one labelling
 and that is also very important - as people will need UDEF, OAGi, and
 more labels for potentially the same term - and then associate them):

  <ContentReference>
   <Addressing>
    <registry name="CCTS" access="registry.my-house.ca:8080"
method="http-binding"
              description="Test CCTS Dictionary Registry access"/>
   </Addressing>

   <item type="noun" name="//BeingTypeIdentifier"
         UIDReference="0021-BeingTypeIdentfier.xml" taxonomy="XMLpath"
registry="CCTS"
         ccts:modeltype="BIE" />

   </ContentReference>

Final point - the human friendly code system can be equated under-the-hood
to the UUID and then the UUID used for all the machine internal linkages -
but it is a mistake to expose the UUID outside of the registry at the human
interface level.  It's confusing, its unnecessary and it is a formidable
turn-off
for people who would otherwise want to adopt ebXML Registry for their
work.  I can give you direct quotes from people looking at screens from
YDS and XMLG registry implementations - WRT UUIDs being displayed
on them - but this is a family channel rated 'G' only!

Cheers, DW.

----- Original Message ----- 
From: "Matthew MacKenzie" <mattm@adobe.com>
To: "'David RR Webber'" <david@drrw.info>; "'Farrukh Najmi'"
<Farrukh.Najmi@Sun.COM>
Cc: "'Duane Nickull'" <dnickull@adobe.com>; "'UN/CEFACT Core Component WG'"
<uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org>
Sent: Saturday, April 10, 2004 10:15 AM
Subject: LONG: RE: [regrep] Issue with UUID's for Core Components and BIE's


> A UUID is meant to be unique in time and space.  Frankly, they are
> universally adopted.  With ebRS supporting a predictable URL format via
its
> HTTP binding, we really should be looking toward defining mechanisms for
> making registry location information available such as in DNS.  A ID
> mechanism that embeds some prefix in it is a hokey solution, and its error
> prone unless each organization manages their namespace carefully.
>
> One idea is to embed some more info in the urn, and use a DNS driven
> approach for resolving an extended urn string to a registry object
download
> URL.
>
> We take a root domain name of 'r.ebxml.org', this is our address space.  A
> committee at OASIS is in charge of maintaining this namespace.
>
> Organization 'A'would like to register its registry, so they submit a
> request to the OASIS team looking after this.  The request might look
like:
>
> "A Corp. would like to register two registry instances in the global
> "directory".  Instance One is called "osirus" and it is at
> http://osirus.corp.com/http-binding.  The second instance is called
> "ogmios", and it is located at http://ogmios.corp.com/http-binding.";
>
> Upon receiving this request, the OASIS team would register a domain name
for
> the organization in DNS:
>
> a.r.ebxml.org.  In the TXT field for that domain, would be a token like:
>
> ORG:A Corp
>
> Two more subdomains would also be created:
>
> Osirus.a.r.ebxml.org
>   --> TXT field: http://osirus.corp.com/http-binding
>
> Ogmios.a.r.ebxml.org
>   --> TXT field: http://osirus.corp.com/http-binding
>
> Federations could be accommodated by creating further sub-domains for
> "virtual" registries, e.g. ogmios.clusterA.a.r.ebxml.org.
>
> Now...The UUID: urn:uuid:osirus:a:UUID-7888-HHHH-UUUU
>
> Using standard DNS resolver libraries + that UUID, we can find out the
HTTP
> binding location.  Since we are using DNS infrastructure, it is likely
that
> no special configuration will be needed, and the system is proven to be
> ultra scalable.
>
> If I get a couple hours, I will demonstrate this technique.
>
> I don't think we need domain specific ID references.  What we need is
unique
> identifiers that can always be resolved to their registry content or
entries
> by authorized users from anywhere.  Nobody cares that the UUID is
difficult
> to type and remember, because these things are used by software.
>
> -matt
>
>
>
> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Friday, April 09, 2004 11:29 AM
> To: Farrukh Najmi
> Cc: Duane Nickull; UN/CEFACT Core Component WG;
regrep@lists.oasis-open.org
> Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's
>
> 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"
>
> 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.
>
>
>
> 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.
>
>