[Standards-JIG] JEP-0060: Comments on latest draft.
bob at wyman.us
Fri Jun 25 21:29:28 UTC 2004
Boyd Fletcher wrote:
> [Many things should be MUST that are not now...]
It is clear that you would like to remove much of the flexibility
from the current JEP-0060 spec. However, I think it is also clear that you
haven't really done a good job of describing why this should be done. It is
entirely possible that a system as rigid as what you propose may meet *your*
requirements -- you haven't proven why such rigidity is going to meet the
requirements of a broader audience. It would be helpful if you could do
that... (Remember: If you really insist that particular options be
implemented -- just build the server yourself of if purchasing one, make
such rigidity part of the RFP... Don't use global standards as a way to
enforce local preferences...)
It is not reasonable to require, as you suggest we do, that all
implementations "MUST" support three different methods of handling multiple
items published with same ItemID. Not all servers will be general purpose.
Additionally, there are reasonable handling strategies that are not in the
list of three that you provide. Thus, in some cases, you would require that
a server implement features that will probably not be used, and in other
cases, you've made a proposal that doesn't seem to allow the introduction of
new methods for handling itemID conflicts.
Personally, I think it would be much more useful if you would focus
less on removing flexibility from the specification and more on ensuring the
removal of ambiguity at run-time. For instance, I think it would be much
more useful if you were to come up with a proposal for how a publisher or
client would be able to determine, at run-time, which strategy would be used
by the node to resolve itemID conflicts. I.e. should the duplicate itemID
handling method be returned as a node configuration item? Is there any case
where it might be desirable to have the method vary between subscriptions to
the same node? (The answer is "Yes" -- especially if persistence is
supported.) Should duplicate handling method be a part of subscription
options setting? Etc... In any case, worry about ambiguity at run-time...
Don't worry about flexibility in the specification.
> When a user subscribes to a node that contains child nodes,
> then any changes to child nodes, their children, or their
> items that generate notifications are sent to the subscriber
> of the parent node.
There are no "child" nodes in JEP-0060. You should probably look at
the current draft of JEP-0060 and study the discussion of collections in
Section 10. Any delivery of items to multiple nodes should be done in the
context of node Collections.
More information about the Standards