[infod-wg] Dependency Graph - update

[Ronny Fehling]

Hi

 

I had an Action Item to create a Dependency Graph for the infoD interfaces. 

While working through that I created the attached graph. 

 



 

 

However, in discussions with Dieter, we discovered some problems:

The manager-interfaces themselves are obeying a vocabulary that was defined in section 6. Also, there are a lot of optional elements in the spec so that the dependency graph degraded itself more into a process order graph. 

However, Dieter discovered that the process order and the dependency structure are best described through two rules:

 

InfoD Rule 1: Vocabularies can only be referenced once they are defined - vocabularies maybe referenced in constraints or in the specification of other vocabularies.

InfoD Rule 2: Instances can only be referenced once they exist - instances maybe referenced in associations or user properties

 

I think they best capture and resolve our issues. They might seem trivial, but if you really think about it, they represent some implicit consequences:

- I can only create a subscription if I have a constraint language vocabulary defined. If I don't put any restriction on the publisher, I don't need to have a publisher nor association defined yet!

 

At the same time, it brings up a couple of questions:

-          What do we want to do if I create a subscription and I do choose to put a constraint on the publisher (e.g. PublisherName has to start with a 'P') and there is no such publisher? Should the subscription be rejected or 'put on hold' until such a publisher is found? What should the subscriber be told? 

-          Even more extreme: If I create a subscription using a constraint language that doesn't exist (yet), should we refuse it or put it on hold? What should the subscriber be told? 

-          Security and Covert Channel: from a pure IT perspective, it seems natural to resolve the previous questions by telling the 'truth' - that there is no such publisher/vocabulary. However, from a security and covert channel perspective, it might be much more desired to give back an answer that doesn't reveal internal aspects of the registry. It might be a security concern to inform a subscriber that there is in fact no publisher for a given subscription. 

 

I propose  we approach this from a building block perspective where at the lowest level, we give complete information (not just accept/refuse, but also 'no publisher yet associated with this vocab'/ 'no matching publisher found' / 'no such vocabulary yet defined') and leave it to a security layer on top to filter out the completeness and/or give additional information to rend the response ambiguous.

 

 

Thanks,

Ronny Fehling
Solutions Architect Manager
Oracle Strategic Development 
Tel/Fax: +1 514 905-8633
Mobile: +1 514 880-8633
ronny.fehling at oracle.com <mailto:ronny.fehling at oracle.com> 
www.oracle.com <http://www.oracle.com/>  
View my Calendar <http://collabsuite.oracle.com/global-bin/ocas.fcgi?sub=web&web=gbl&viw=%85%97%97%94%82%f2%9b%9b%97%ac%a8%ac%a4%a4%aa%b4%a6%ab%a5%af%c5%af%a2%a3&xen=%e5%ea%e1%e2%f4%e9%ed%ee> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20060303/9de59776/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 34656 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060303/9de59776/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.emz
Type: application/octet-stream
Size: 8823 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060303/9de59776/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 33207 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20060303/9de59776/attachment.gif