OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]