[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]