[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [uddi-spec] Comments on future intentions for V3
Hi Matthew, Item A is an interesting proposal. It could also be quite useful. I also see it as a v4 feature candidate. I don't see a reasonable way to do this as a BP/TN since realistically it entails a schema change. Seems to me this would best be done with an new type - an alternative to a keyed reference and being prescriptive where it can be used. Simply changing the cardinality of keyValue on keyedReference has a lot of implications throughout the data model that we'd have to be pretty careful of. Can you propose some additional use cases where this would be valuable? As for item B, I think a lot of questions need to be answered before I'd see value in pushing it forward, such as: How are the synonym relationships established and maintained? How do you handle this for an inumerable number of languages? To what fields does it apply? Can it be used in conjunction with approximateMatch? Etc, etc... This could be a real nightmare. Also - how much value is there here - strong use cases would help establish that. Got any? Thanks, Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 (internal) Co-Chair, OASIS UDDI Specification TC "Matthew Dovey" <matthew.dovey@las.ox.ac.uk> on 11/14/2002 05:10:34 PM To: Tom Bellwood/Austin/IBM@IBMUS, <uddi-spec@lists.oasis-open.org> cc: Subject: RE: [uddi-spec] Comments on future intentions for V3 > Hi Matthew - sorry you couldn't make the meeting. <snip> > New features > though (like the juicy list we came up with whilst > brainstorming during yesterday's FTF - whichy should come out > in the minutes soon) are all candidates for a UDDI V4 as well as Best > Practices/Technical Notes where applicable, NOT as changes to > V3. There were a couple of new features/BP/TN's I wanted to raise based on comments I made back in June and have been wondering about drafting a TN/BP proposal for Namely: A) handling different semantics for matching keyReferences beyond those specified in the spec (i.e. ... a match occurs if and only if 1) the tModelKeys refer to the same tModel and 2) the keyValues are identical. The keyNames are not significant. ...) Basically this would allow a keyReference to behave as a vector rather than a set of scalar values Two ways might be possible - either the tModel can override these semantics or search qualifier might override these B) a search qualifier for synonym matches (and related resolution WebServices and tModels) Both of these were thought to involve too much feature creep and/or open too many issues to be considered in order to be in v3. If neither of these are on the juicy list, can I propose to add them? If they are, I'd be happy to participate in fleshing these out. Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC