RE: [uddi-spec] Namespace management (corrected spelling)

[Andrew Hately <hately@us.ibm.com>]

This does seem to be a long thread centered on two
main issues.  The first is a use case for registering namespaces in
a regstry that allows for uniqueness to be enforced.  The second is
a discussion about the appropriateness of using tModels and the current
UDDI modeling for this type of information artifact and other issues.  Managing
namespaces (not just registering) or managing any data artifact is beyond
the scope we've had for the UDDI registry... unless of course the definition
of manage for the particular artifiact is register for indexing and discovery
against the UDDI meta-data.

As for the first issue, a convention could be established
whereby a keySpace could be established in a registry, and the tModelKey(s)
could represent the namespace itself and by virtue of their uniqueness
it is possible to address the original concern posted by Max...  the
tModel could then reference documentation explaining the meaning of that
namespace.  

As for the other issue about appropriateness of tModels,
I'll comment on the following two snippets from this long email thread.

>At this time all of these concepts are represented
as raw tModels with no semantic differentiation

The differentiation is intended to be
in the publisher supplied names, descriptions, categorizations, URLs, etc...
Some of this is machine readable/interpretable and some of it requires
human interpretation.  I believe that using good modeling practices,
the tModels can be differentiated sufficiently.

>It can be
shown that tModels (along with their contained keyedReferences) alone permit
the modeling of an arbitrary information set all within a UDDI registry.

This is intentional.  The focus
has been to ensure that the data model makes Web service modeling convenient
and straight forward, but also that the data model is extensible enough
to register other concepts.  Misuse of structures or propogation of
useless data in a registry can occur regardless of what restrictions we
put on data structures.

Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies

Daniel Feygin <feygin@unitspace.com>

03/12/2003 11:37 AM

To	"'Anne Thomas Manes'" <anne@manes.net>, "'Rogers, Tony'" <Tony.Rogers@ca.com>, "'Max Voskob'" <mvoskob@msi.com.au>, "'uddi-spec'" <uddi-spec@lists.oasis-open.org>
cc
Subject	RE: [uddi-spec] Namespace management (corrected spelling)

I do not have any objections to that, but it really
wouldn't do anything to
correct what I perceive as a somewhat problematic area in the design of
UDDI
information model.


> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net] 
> Sent: Wednesday, March 12, 2003 7:48 PM
> To: Daniel Feygin; 'Rogers, Tony'; 'Max Voskob'; 'uddi-spec'
> Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> 
> 
> I think it should cover more than just "applying a value 
> set". I'd liek to see a best practice document that makes 
> recommendations for designing and using taxonomies, whether 
> or not they provide a value set.
> 
> Anne
> 
> > -----Original Message-----
> > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > Sent: Wednesday, March 12, 2003 10:24 AM
> > To: 'Anne Thomas Manes'; 'Rogers, Tony'; 'Max Voskob'; 'uddi-spec'
> > Subject: RE: [uddi-spec] Namespace management (corrected spelling)
> >
> >
> > Anne,
> >
> > Can you be more specific?  Do you mean something like "Applying
a 
> > value set in UDDI" (to complement the existing TN 
> "Providing A Value 
> > Set For Use In UDDI Version 3" -
> > http://oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-
> > valuesetpr
> > ovider-20030212.htm)?  I don't think that would alleviate
> the issue I am
> > trying to raise, because I am pointing to potential misuse of
the
> > capabilities that would still remain in the spec.
> >
> > Daniel
> >
> >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > Sent: Wednesday, March 12, 2003 4:33 PM
> > > To: Daniel Feygin; 'Rogers, Tony'; 'Max Voskob'; 'uddi-spec'
> > > Subject: RE: [uddi-spec] Namespace management (corrected
spelling)
> > >
> > >
> > > I think we need a technical note (best practice) on how
to use 
> > > keyedReferences.
> > >
> > > > -----Original Message-----
> > > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > > Sent: Wednesday, March 12, 2003 3:25 AM
> > > > To: 'Rogers, Tony'; 'Anne Thomas Manes'; 'Max Voskob';
> 'uddi-spec'
> > > > Subject: RE: [uddi-spec] Namespace management 
> (corrected spelling)
> > > >
> > > >
> > > > Anne, Max, Tony,
> > > >
> > > > I am not too happy with a 'plethora of specialised
bags'
> > > myself, but I
> > > > see it as a potential replacement (lesser?) evil to
the
> > > super-flexible
> > > > tModel super-structure, which almost invites misuse
and
> > > overuse.  It
> > > > can be shown that tModels (along with their contained
> > > keyedReferences)
> > > > alone permit the modeling of an arbitrary information
set
> > > all within a
> > > > UDDI registry.  If everybody else is comfortable
with 
> that, then I 
> > > > rest my case.
> > > >
> > > > Daniel
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
> > > > > Sent: Wednesday, March 12, 2003 2:23 AM
> > > > > To: Daniel Feygin; Anne Thomas Manes; Max Voskob;
uddi-spec
> > > > > Subject: RE: [uddi-spec] Namespace management
(corrected 
> > > > > spelling)
> > > > >
> > > > >
> > > > > This effect can be achieved, albeit a little less
> > > conveniently, by
> > > > > defining categorisation tModels for these categories
(eg: 
> > > > > "processCategory"), then marking the
tModels that would
> > > be used in
> > > > > the specialised bags with those categories. Taking
your first 
> > > > > example, the tModel you are using for 
> > > > > "abc.org:processes:DirectMaterialsProcurement_v1.0"
> > > > > would be marked as a "processCategory".
Then the user can
> > > find all
> > > > > instances of "processCategoryBag" entries
by locating all 
> > > > > tModels that have the "processCategory"
in their 
> category bag, 
> > > > > and then finding all the matching entries. If
they are 
> > > > > businesses,
> > > a nested
> > > > > findTModel in the findBusiness would do the job
nicely.
> > > > >
> > > > > Sure, it isn't as simple, but it does avoid cluttering
> > > what should
> > > > > be a general purpose data design with a plethora
of 
> specialised 
> > > > > bags. I'm of the opinion that the UDDI data design
is already 
> > > > > over-provided with specialised types - I'd far
prefer 
> to see a 
> > > > > reduction in the number of types than an increase.
> > > > >
> > > > > Hmm - sorry if that got into a bit of a rant -
I've been 
> > > > > fighting with some obstreperous code, and sometimes
> it makes be 
> > > > > grumpy :-)
> > > > >
> > > > > Tony Rogers
> > > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Feygin [mailto:feygin@unitspace.com]
> > > > > Sent: Wednesday, 12 March 2003 0:26
> > > > > To: 'Anne Thomas Manes'; 'Max Voskob'; 'uddi-spec'
> > > > > Subject: RE: [uddi-spec] Namespace management
(corrected 
> > > > > spelling)
> > > > >
> > > > >
> > > > > Anne,
> > > > >
> > > > > I mean that there could be specialized derivations
of
> > > categoryBags,
> > > > > keyedReferences and tModels instead of the generic
> ones.  Their 
> > > > > meaning would be more apparent to users and they
would
> > > more closely
> > > > > follow the semantics of the concepts they are
used to model.  
> > > > > For example, there could be specialized categoryBags
to
> > > denote process
> > > > > flows called processCategories, schemaCategories
for 
> schemas and 
> > > > > businessCategories for traditional taxonomies
(examples below 
> > > > > are only to demonstrate the overall modeling 
> principles of the 
> > > > > approach): <processCategories>
> > > > >   <processReference
> > > > >     
> processKey="abc.org:processes:DirectMaterialsProcurement_v1.0"
> > > > >     roleValue="seller" />
> > > > > </processCategories>
> > > > > <schemaCategories>
> > > > >   <schemaReference
> > > > >     schemaKey="open-applications.org:schemas:OAGIS_v8.0"
/> 
> > > > > </schemaCategories> <businessCategories>
> > > > >   <taxonomyReference
> > > > >     taxonomyKey="uddi:uddi.org:categorization:unspsc"
> > > > >     keyName="UNSPSC: Livestock"
> > > > >     keyValue="101015" />
> > > > > </businessCategories>
> > > > >
> > > > > When an inquiry on a given categorization is performed,
> > > the inquirer
> > > > > is certainly aware that what is being searched
on is a
> > > process flow,
> > > > > business taxonomy or UDDI-specific concept (such
as
> > > owningBusiness
> > > > > or isReplacedBy), so there would be no adverse
impact for 
> > > > > inquiry use patterns.  The same applies to
publication.
> > > > >
> > > > > This approach would imply that generally we might
consider 
> > > > > making such specialized derivations for the types
of tModels 
> > > > > that correspond to the values in the uddi-org:types
category
> > > system.  At
> > > > > this time all of these concepts are represented
as raw
> > > tModels with
> > > > > no semantic differentiation, although it is apparent
that
> > > they vary
> > > > > greatly in their intended use.
> > > > >
> > > > > Daniel
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Anne Thomas Manes [mailto:anne@manes.net]
> > > > > > Sent: Sunday, March 09, 2003 11:38 PM
> > > > > > To: Max Voskob; 'uddi-spec'
> > > > > > Subject: RE: [uddi-spec] Namespace management
> > > (corrected spelling)
> > > > > >
> > > > > >
> > > > > > Daniel,
> > > > > >
> > > > > > Can you explain more what you mean by task-oriented
> > > > > > structures?
> > > > > >
> > > > > > I don't really see a necessity to create
a host of
> > > > > different entities
> > > > > > to represent different technical models,
specifications,
> > > > > frameworks,
> > > > > > or process flows, but perhaps I don't quite
understand
> > > what you're
> > > > > > trying to accomplish.
> > > > > >
> > > > > > tModels are typed. Therefore each tModel
type can represent
> > > > > different
> > > > > > information. Because tModels have been designed
to 
> be generic, 
> > > > > > they can represent pretty much anything --
including tasks.
> > > > > >
> > > > > > keyedReferences let you associate tModels
anyway you
> > > want to. For
> > > > > > example, in Max's e-government example, you
could associate
> > > > > a set of
> > > > > > related tModels via a framework meta-namespace
(or
> > > whatever naming
> > > > > > scheme you want to use).
> > > > > >
> > > > > > Anne
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > > > > > Sent: Sunday, March 09, 2003 1:26 PM
> > > > > > > To: 'uddi-spec'
> > > > > > > Subject: Re: [uddi-spec] Namespace management
(corrected
> > > > > > > spelling)
> > > > > > >
> > > > > > >
> > > > > > > Hi Daniel,
> > > > > > >
> > > > > > > I agree with what you say, but there
is a good
> > > example of ebXML
> > > > > > > Registry for us to avoid.
> > > > > > >
> > > > > > > They have their specialized entities,
highly customized
> > > > > > datamodel and
> > > > > > > other complexities. It doesn't make
their spec thinner
> > > > > than the UDDI
> > > > > > > spec nor less complex or ambiguous.
UDDI is an
> > > obvious winner in
> > > > > > > this respect. UDDI can do more with
less. Isn't it a
> > > good thing?
> > > > > > >
> > > > > > > We may need to change such basic concepts
as tModel and
> > > > > > key-name-value
> > > > > > > in the future, but there is a way around
it for now. Users
> > > > > > (customers)
> > > > > > > do not want to wait another couple of
years for v.4 :(
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Max
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Daniel Feygin" <feygin@unitspace.com>
> > > > > > > To: "'Max Voskob'" <mvoskob@msi.net.nz>;
"'uddi-spec'" 
> > > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > > Sent: Monday, March 10, 2003 1:22 AM
> > > > > > > Subject: RE: [uddi-spec] Namespace management
(corrected
> > > > > > > spelling)
> > > > > > >
> > > > > > >
> > > > > > > > Max, TC,
> > > > > > > >
> > > > > > > > I would group all the information
artifacts you 
> refer to 
> > > > > > > > as metadata, which would help to
differentiate it from
> > > business
> > > > > > > > content.  As I briefly mentioned
in my previous
> > > > > message, UDDI is
> > > > > > > > capable of storing references to
any metadata 
> files using
> > > > > > tModels,
> > > > > > > > although it should be explored
what needs to be done to
> > > > > > make service
> > > > > > > > metadata more workable and useful
in UDDI.
> > > > > > > >
> > > > > > > > It is possible that this can be
adequately 
> addressed with
> > > > > > additional
> > > > > > > > guidance/use cases on the current
capabilities of UDDI. 
> > > > > > > > Another possibility is to re-design
everything 
> related to
> > > > > > tModels/metadata
> > > > > > > > in V4 (or later), because tModels
may be perceived
> > > as somewhat
> > > > > > > > functionally overloaded (and therefore
overwhelming to
> > > > > > the developer
> > > > > > > > community) - they are used for
several *distinct*
> > > > > > purposes ranging
> > > > > > > > from categorizations (real-world
taxonomies) and Web
> > > > > > service types
> > > > > > > > (e.g.
> > > > > > > > WSDL) to system-specific concepts
(as in owningBusiness 
> > > > > > > > and
> > > > > > > > isReplacedBy) and would-be metadata
like schemas (e.g.,
> > > > > > XSD), process
> > > > > > > > definitions (e.g., BPEL4WS, WSCI)
and other (possibly
> > > > > > QoS, fail-over and
> > > > > > > > load-balancing alternatives, etc.).
> > > > > > > >
> > > > > > > > It seems that tModels and keyedReferences
were intended
> > > > > > to be very
> > > > > > > > flexible so as to satisfy a broad
range of
> > > unidentified future
> > > > > > > > requirements through modeling and
gluing together
> > > of different
> > > > > > > > features entirely as tModels and
keyedReferences.
> > > Indeed they
> > > > > > > > enable a great variety of unforeseen
circumstances and
> > > > > > requirements
> > > > > > > > to be addressed. Now that many
of these 
> requirements have 
> > > > > > > > become known, perhaps it is time
for them to be modeled
> > > > > > differently using
> > > > > > > > more solid task-oriented structures.
> > > > > > > >
> > > > > > > > Daniel
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Max Voskob [mailto:mvoskob@msi.com.au]
> > > > > > > > > Sent: Thursday, March 06,
2003 12:10 AM
> > > > > > > > > To: uddi-spec
> > > > > > > > > Subject: Re: [uddi-spec] Namespace
management
> > > > > > (corrected spelling)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Daniel,
> > > > > > > > >
> > > > > > > > > The information artifacts
can be almost anything,
> > > e.g., XML
> > > > > > > > > schemas, documentation, sample
XML documents, WSDL 
> > > > > > > > > files, namespace identifiers,
documents for 
> ebXML (CPP, 
> > > > > > > > > CPA,
> > > > > etc), XML
> > > > > > > > > Topic Maps files, taxonomies,
etc, etc, etc.
> > > > > > > > >
> > > > > > > > > Web services do not exist
on its own. If the
> > > webservice is
> > > > > > > > > as simple as RPC then it's
easy, but what if it's
> > > a complex
> > > > > > > > > one? Let's say "CreateCustomer"
web-service when a 
> > > > > > > > > complex
> > > > > > XML document
> > > > > > > > > is passed onto the web-service
and an even more
> > > complex XML
> > > > > > > > > document is returned back.
Those documents may contain
> > > > > > a dosen of
> > > > > > > > > infosets from different namespaces
and so on. Another
> > > > > > example is a
> > > > > > > > > popular 360 degree view of
customer information
> > > (basically
> > > > > > > > > any
> > > > > > > > > information) where all entities
are described using
> > > > > XML Schemas
> > > > > > > > > and linked together to form
one enterprise- /
> > > government- /
> > > > > > > > > industry- / national - wide
framework. (see the
> > > > > > attached picture)
> > > > > > > > >
> > > > > > > > > Take for example an e-Government.
They adopt or
> > > > > produce schemas
> > > > > > > > > for election, name, address,
etc. These schemas,
> > > > > again, form a
> > > > > > > > > framework.
> > > > > > > > >
> > > > > > > > > The framework components are
registered in 
> the registry
> > > > > > and stored
> > > > > > > > > elsewhere. If I have a NS
identifier I go to the
> > > > > > registry and find
> > > > > > > > > everything that relates to
that NS ID, including
> > > the schema,
> > > > > > > > > documentation for the schema,
sample XML files, who
> > > > > > wrote it, who
> > > > > > > > > use it, what status of each
document is and 
> all sort of 
> > > > > > > > > other crucial information.
> > > > > > > > >
> > > > > > > > > All those information artifacts
still relate to
> > > > > > web-services. For
> > > > > > > > > example, a WS A recieves an
XML document with 3 
> > > > > > > > > different namespaces. The
web service can deal with 2 
> > > > > > > > > only and
> > > > > > then has to
> > > > > > > > > pass the document to another
web service for
> > > > > > processing. The WS A
> > > > > > > > > looks up the registry to find
the webservice by at say
> > > > > > NS ID and
> > > > > > > > > get all the binding it needs
to call it. I think
> > > > > there can be a
> > > > > > > > > hundred of other runtime interaction
example.
> > > > > > > > >
> > > > > > > > > Web-services do not come on
their own. They depend on
> > > > > > many other
> > > > > > > > > information artifacts that
may be required for their
> > > > > > processing at
> > > > > > > > > runtime or development (design
time). Speaking of the 
> > > > > > > > > multiple purposes I mean that
for private 
> registries the 
> > > > > > > > > content
> > > > > > cannot be
> > > > > > > > > limited to just "business"
and "service". It is much
> > > > > > broader than
> > > > > > > > > that.
> > > > > > > > >
> > > > > > > > > Customers want to have one
registry for all artifacts
> > > > > > and do not
> > > > > > > > > spread the $$$, time and effort
across UDDI for WS,
> > > > > > ebXML registry
> > > > > > > > > for schemas and other stuff,
Tibco for something else
> > > > > > and so on.
> > > > > > > > > Customers want one registry
to rule them all.
> > > > > > > > >
> > > > > > > > > Sorry, I'm not sure I expressed
myself clearly.
> > > Please, let
> > > > > > > > > me know if it's still confusing.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Max
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Daniel Feygin"
<feygin@unitspace.com>
> > > > > > > > > To: "'Max Voskob'"
<mvoskob@msi.net.nz>; 
> "'uddi-spec'" 
> > > > > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > > > > Sent: Wednesday, March 05,
2003 1:36 AM
> > > > > > > > > Subject: RE: [uddi-spec] Namespace
management
> > > > > > (corrected spelling)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Max,
> > > > > > > > > >
> > > > > > > > > > It could certainly make
for an interesting 
> discussion, 
> > > > > > > > > > particularly since it
is substantiated by
> > > specific client
> > > > > > > > > > references.
> > > > > > > > > We do have
> > > > > > > > > > UDDI managing WSDL registrations
and there 
> is really 
> > > > > > > > > > nothing technically preventing
anyone from, say,
> > > > > registering process
> > > > > > > > > > specifications or schema
references in UDDI
> > > using tModels
> > > > > > > > > (other than
> > > > > > > > > > that there are no use
cases or guidance for
> > > doing so in a
> > > > > > > > > uniform and
> > > > > > > > > > recognizable way).
> > > > > > > > > >
> > > > > > > > > > In terms of business
content, I - and UnitSpace
> > > - see UDDI
> > > > > > > > > > already being a registry
of content 
> *services*; these
> > > > > > services
> > > > > > > > > > are where business information
entities can be
> > > discovered,
> > > > > > > > > > retrieved and managed.
 But there is a
> > > difference between
> > > > > > > > > > maintaining service metadata
and business content.
> > > > > Extending
> > > > > > > > > > UDDI to perform business
content management
> > > would require
> > > > > > > > > > substantial, though probably
backwards-compatible,
> > > > > changes to
> > > > > > > > > > the information model
and
> > > > > > > > > the API's.
> > > > > > > > > > My fear is that most
business content has a
> > > > > different profile
> > > > > > > > > > that metadata with regard
to security, applicable
> > > > > operations,
> > > > > > > > > > functional role and target
users, although that's
> > > > > > debatable and
> > > > > > > > > > perhaps a plausible alignment
other than proposed
> > > > > > above ("UDDI
> > > > > > > > > > is a
> > > > > > > > > registry of
> > > > > > > > > > content services, which
in turn manage content") is
> > > > > possible.
> > > > > > > > > >
> > > > > > > > > > I guess it would be helpful
to understand more
> > > > > > specifically what
> > > > > > > > > > is being proposed for
discussion.  My 
> questions to Max
> > > > > > > > > therefore are: 1.
> > > > > > > > > > What sort of information
artifacts are you
> > > referring to?
> > > > > > > > > > 2. Specifically, what
are the attempted
> > > multiple purposes
> > > > > > > > > > of
> > > > > > > > > using UDDI
> > > > > > > > > > that you came across?
> > > > > > > > > >
> > > > > > > > > > Best regards,
> > > > > > > > > > Daniel
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Max Voskob
[mailto:mvoskob@msi.com.au]
> > > > > > > > > > > Sent: Monday, March
03, 2003 9:52 PM
> > > > > > > > > > > To: uddi-spec
> > > > > > > > > > > Subject: Re: [uddi-spec]
Namespace management
> > > (corrected
> > > > > > > > > > > spelling)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Matthew,
> > > > > > > > > > >
> > > > > > > > > > > That's the problem.
UDDI is being considered
> > > by many as
> > > > > > > > > > > a
> > > > > > > > > registry
> > > > > > > > > > > of informational
artifacts for an enterprise. I'm
> > > > > > one of them.
> > > > > > > > > > > :) And UDDI is almost
there! It's got a huge
> > > > > > potential, much
> > > > > > > > > > > more potential then
any competing standard at the
> > > > > > moment. All
> > > > > > > > > we need is
> > > > > > > > > > > a little effort
to get the external
> > > taxonomies going and
> > > > > > > > > > > probably add a couple
more minor features without
> > > > > > changing the
> > > > > > > > > > > concept. On the
other hand I can't see the
> > > > > > consensus amongst
> > > > > > > > > > > the members to rephrase
the purpose of UDDI.
> > > > > > > > > > >
> > > > > > > > > > > I personally came
across quite a few cases where
> > > > > > organisations
> > > > > > > > > > > (incl. NZ Gov, OZ
Gov) were seriously considering
> > > > > UDDI as a
> > > > > > > > > > > multi-purpose registry.
They did so not from
> > > > > > misunderstanding
> > > > > > > > > > > of UDDI, but from
seeing a great potential in the
> > > > > > standard and
> > > > > > > > > > > its implementations.
> > > > > > > > > > >
> > > > > > > > > > > I would suggest
to include it in the 
> agenda of one 
> > > > > > > > > > > of the
> > > > > > > > > upcoming
> > > > > > > > > > > telecons and discuss
it openly, if the other TC
> > > > > members are
> > > > > > > > > > > interested, of coz.
> > > > > > > > > > >
> > > > > > > > > > > Cheers,
> > > > > > > > > > > Max
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ----- Original Message
-----
> > > > > > > > > > > From: "Matthew
Dovey" <matthew.dovey@las.ox.ac.uk>
> > > > > > > > > > > To: "Max Voskob"
<mvoskob@msi.net.nz>; 
> "uddi-spec" 
> > > > > > > > > > > <uddi-spec@lists.oasis-open.org>
> > > > > > > > > > > Sent: Tuesday, March
04, 2003 4:16 AM
> > > > > > > > > > > Subject: RE: [uddi-spec]
Namespace management
> > > (corrected
> > > > > > > > > > > spelling)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This sounds like
the problem space that metadata
> > > > > > > > > registries and ISO
> > > > > > > > > > > 11179 aim to address
(see
> > > > > > http://www.schemas-forum.org/ for a
> > > > > > > > > > > EU project in this
area).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I'm pretty sure
that this isn't a question
> > > that UDDI has
> > > > > > > > > attempted
> > > > > > > > > > > to tackle. I'm not
entirely sure whether it is a 
> > > > > > > > > > > question
> > > > > > > > > that UDDI
> > > > > > > > > > > should tackle -
my undertanding is that UDDI is a
> > > > > > directory of
> > > > > > > > > > > WebServices rather
than a universal directory for
> > > > > > everything
> > > > > > > > > > > Web/WebService related
(but that's just 
> my opinion)
> > > > > > > > > > >
> > > > > > > > > > > Matthew
> > > > > > > > > > >
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > <snip>
> > > > > > > > > > >
> > > > > > > > > > > Imagine an organisation
where 25 departments are 
> > > > > > > > > > > creating
> > > > > > > > > different
> > > > > > > > > > > XML documents and
formalise them with all 
> sorts of 
> > > > > > > > > > > documentation including
XML Schemas. How do they
> > > > > > ensure that
> > > > > > > > > > > the new
> > > > > > > > > namespace ID
> > > > > > > > > > > they've just come
up with is not already used
> > > somewhere
> > > > > > > > > else within
> > > > > > > > > > > the organisation?
Sure, they can write a 25 page 
> > > > > > > > > > > guide
> > > > > > > > > how to name
> > > > > > > > > > > their namespaces
(if they can't they email me and 
> > > > > > > > > > > I'll
> > > > > > > > > write one for
> > > > > > > > > > > them :), but it's
hard to reinforce anyway.
> > > > > > > > > > >
> > > > > > > > > > > <snip>
> > > > > > > > > > > Can one do it using
available UDDI means at
> > > the moment?
> > > > > > > > > > > I don't think so,
but I can be wrong. Please
> > > correct me.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > 
> --------------------------------------------------------------
> > > > > > --
> > > > > > > > > > To subscribe or unsubscribe
from this elist use the
> > > > > > subscription
> > > > > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > ------------------------------------------------------------
> > > > > > > > > --
> > > > > > > > > --------------
> > > > > > > > > ----
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > --
> > > > > > > > To subscribe or unsubscribe from
this elist use the
> > > subscription
> > > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > ----------------------------------------------------------------
> > > > > > > To subscribe or unsubscribe from this
elist use the
> > > subscription
> > > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > 
> --------------------------------------------------------------
> > > > > > --
> > > > > > To subscribe or unsubscribe from this elist
use the 
> subscription
> > > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > > >
> > > > >
> > > > >
> > > > > 
> ----------------------------------------------------------------
> > > > > To subscribe or unsubscribe from this elist use
the 
> subscription
> > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > > >
> > > > >
> > > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>