12/21/2006 1:20 PM
post5724
|
Comments from Rick Hayes-Roth (Submitted by Steve Fisher)
These should have been uploaded before (Steve)
------------------------------------------------------------
I have reviewed the InfoD draft specification and request that you publish my comments if you find them helpful. I've
also marked up the draft document with many lower-level comments, questions, concerns and errata. My message here will
focus on major, high-level comments.
(1) I believe the purpose of the document, to enable open, web-enabled, dissemination of events is important.
(2) I don't believe the specification as written is self-explanatory. It doesn't contain enough use cases or worked
examples. It doesn't describe the major business patterns of use anticipated. As a result, I can't be sure it'll work
well, for anything. Worse, I can't grok what contextual assumptions its really making that will determine the
suitability of implementations. It's too abstract, too low-level, too detailed for an interested party to assess, as
written.
(3) I think the spec mixes several concerns that ideally would be separable. These are the ones I discern:
(a) characterizing the information a supplier can provide;
(b) characterizing the consumers a supplier is willing to serve as well as the condiions under which the supplier is
willing to serve the consumer(s);
(c) characterizing the information a consumer wishes to obtain;
(d) characterizing the suppliers a consumer is willing to take information from as well as the conditions under which
the consumer is willing to consume from the supplier(s);
(e) establishing supply contracts between one supplier and one consumer;
(f) establishing high quality supply service level agreements (SLAs), between N consumers and M suppliers;
(g) defining life-cycle, continuity, sunset, and other terms of the supply SLAs;
(h) defining dissemination methods available for use in moving information;
(i) characterizing which dissemination methods can and should be used in which supply contracts and SLAs;
(j) how constraints are defined and how processed;
(k) how a consumer's desired information is specified, how a supplier's supplied information is specified, and how it's
determined whether a particular set of information from a supplier should be delivered to a consumer (i.e., how
'collaborative filtering' is computed); further, what sets of matching problems are too hard, because the complexity is
too great;
(l) how security can be handled, using a variety of credible, current patterns, as opposed to somewhat poorly with just
one;
(m) how this proposed specification complements others and competes with or supersedes others--i.e., what family of
technologies and related efforts does this augment and which does it try to leave behind?
Beyond these general concerns, I'd like to point out that the use case document in the OGF library was unreadable, so my
effort to try to fill out my understanding was unsuccessful.
I hope these comments are helpful. I wish you success in this effort,
Rick
|
|
|