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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: Re: [regrep] Issues with extramural Association

On the other hand, I would suggest to let every party set up maximum pending
time. If there is no response from one of the parties within that period the
request for the extramural association is being deleted. It will be very
easy to implement and the registry won't be littered with outdated pending
requests. Zero value of the max. pending time can mean that it's unlimited.
A minimal value (1 unit?) can mean that the organization is not interested
in any extramural associations and any request will be deleted with the next
scheduled job in the DB.

Does it all make sense? ;)

I can see something like this being useful, but I don't see how it would
work (for example, what is "maximum pending time" attached to (see UseCase
below)? Submitted Object?).

BTW, I was one of the few who didn't like restrictions of this "feature" and
still feel that it shouldn't be that rigid. Question is where the
customization happens: in the speced way or above it. As I said, my
inclination is that customization shouldn't be speced, just allowed.

Also, we need to be aware that our Extramural Associations are not between
Organizations (Businesses) only (as in some other efforts). They could
involve any registry objects. Imagine custom ClassificationScheme /
ClassificationNodes submitted by Somebody and that Somebody subsequently
submitting EquivalentTo Association between some of its nodes and nodes from
"Registry Bootstrapped" ClassificationScheme/Nodes. Why would
"RegistryAsABootstrapCSNSubmitter" be required to confirm these Associations
(possibly many of them) in order form them to be visible? And why would they
be automatically removed?


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

Powered by eList eXpress LLC