RE: What is in what where anyway, and why?

[David RR Webber <Gnosis_@compuserve.com>]

Message text written by Lisa Carnahan
>
Joel,

Could you please clarify what you mean by " a possible
concept of the Oasis Registry TC accepting UDDI as its "Registry" allowing
the Oasis Registry TC to complete its definition of the Repository
functionality and specification."?  Specifically your use of the terms 
'registry' and 'repository'?  Currently our specs are relatively silent on 
the content in the repository.  In fact, most of our work has been on the 
information model/services that make use of the metadata in a 
registry.  Our specs would be fairly content-free if we focused on the 
repository.  Am I missing something here?

--lisa
<<<<<<<<<<<<<

Lisa,

Seeing you raised this question.

For me the distinction between business process artifacts and
their metadata is not a clear one - and certainly not one that
end users understand right now.  We need to fix this.

I've always resolved this by noting that business transactional
data - ie records, XML business documents, are the meat and 
drink of your backend repository - ie Oracle DB, DB2, SQLServer,
et al.

Therefore the business process artifacts are the domain of the
registry - i.e static reference content under version control - 
such as including CPP's, and the Core Components, and
things like Validation Tables, country codes, currencies et al,
and Classification schemes and scheme instances (NAICS etc).

This is somewhat of a departure - but one that is based on 
reality - since you cannot actually stop people storing all these
XML based artifacts in the registry together - and I think we've 
always known that holding that line is impossible - but for
V1.0 we had to make some artificial lines.

So - the emperor has no clothes on?  Under these terms of
reference - the who is who's repository for what registry is
no longer an issue.  Content is content.  If its a static business
process artifact - look for it in ebXML Registry.  If its business
directory information and web service nodes - look for it in UDDI,
if its the price and availablity of 1,000 parts of widgets - 
look for it in your backend legacy repository.  UDDI web service
definition exposes a simple link via a TModel to the ebXML 
Registry - CPP/BPSS/CC assemblies - that actually get the 
job done and delivered via the TRP drivers.

This is a clear and clean delination that implementers can
see and understand without confusion.   

This also enables us to solve all the issues on query by 
making those facilities operate on the registry - instead of some 
artificial two-step look-here-then-there re-direction 
exercise when the content rightly should all be contiguous.
If you want the meta-data - ask for it - else get the 
reference content directly.  Browse and drill down allows
you to navigate the classification and relate that directly
to the business content.

I definately offer this in the spirit of evolving toward a simpler
model that allows us to cleanly support our existing content,
and then the UDDI needs and more directly from the one base.

Thanks, DW.