RE: A proposal for an ebXML Publish Subscribe Service

[David RR Webber <Gnosis_@compuserve.com>]

Scott,

The current TA doc' points out EXPLICITLY that any content
placed in an ebXML Registry is open.  This differs from an
OASIS registry where 'pay' is a property and 'security'.

In the latest DTD's I'm working on for OASIS and ebXML 
I have added <Access>.  However, this is a simpler context
in that it uses <Channel> to classify a whole domain of 
information.  This does not conflict with the overall ebXML 
TA doc' and Requirements, since it provides rights at the
<Classification> layer.  Example - if a Registry contains
both AIAG and GCI information, I may only have access to
the AIAG information, not both.   This mechanism is mainly
a <filter> rather than a security system, since I would only
want results returned to me to be AIAG specific.

Therefore - I would STRONGLY argue that we have 
enough access control right now in our model, and that
providing more is out-of-scope at this time.    If you want
a tightly controlled information model - use an OASIS 
Registry.

Thanks, DW.
=========================================================
Message text written by "Nieman, Scott"
> 
Yes, but it was in the original architecture, and I think its critical for
the concept of distributed reg-reps.  I do believe, having slept on it a
bit, we need another class or two in the information model for subscribing
to a registered object.  

This should not be that difficult.  Here are some potential functional
requirements:
1) the ability to specify what "level" of granularity the subscription
should be.  specifically,  provide the ability to subscribe to one item at
a
time, or a collection of items based on a classification scheme node
(according to current state of the specification)  
2) The ability to define the event level when I am notified; e.g., the
registered object is versioned, someone looked at it or downloaded it, etc.
3) WHO can subscribe is important.  By default the SO, but "Guests" can
too,
specifically if the WHO is another registry.  
4) WHAT is published should only be the metadata, not the object itself.

On a technical note, and to stir debate, perhaps publishing is initiated
via
event trapping instead of (a)synchronous calls by the registry.  that may
be
an implementation issue, but it does affect the proposed client interface.
I think this could also be modeling by listening to a logging service
instead of the registry "knowing" that it needs to call the interface.
Logging is also in the original requirements.

Regards,
<