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

[Daniel Feygin <feygin@unitspace.com>]

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>