[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]