ebxml-regrep message

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


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: A proposal for an ebXML Publish Subscribe Service


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 

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
1) the ability to specify what "level" of granularity the subscription
should be.  specifically,  provide the ability to subscribe to one item at
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
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
event trapping instead of (a)synchronous calls by the registry.  that may
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC