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