[OASIS Issue Tracker] Commented: (SAF-16) Types Registry

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/SAF-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24900#action_24900 ] 

Stavros Isaiadis  commented on SAF-16:
--------------------------------------

Some previous discussions:

Types Store might include semantic information, e.g. schema for the Symptom content, and arguments for Prescription Types, as this is going or be very handy for Symptom and Protocol/Prescription constructors or handlers. 

Is this an extension to the Catalog or a separate store? Implementation details remain abstracted. 

Paul: why before we didn't think about this? Dave: drilling down in the Cloud use case, we discovered that significant value is in integrating domains, hence knowing what is happening in other domains, and this is very helpful. 

Paul: Types store might not be needed since Syndrome author defines syndromes and symptoms first and then emitters "adopt" the specified symptoms types. Stavros: what if emitters exist already, and a client wants to build his system from scratch and wants to know what is already available? Vivian: if we cannot strongly favor the importance of the Types Store, we could add this info as extension to the Catalog or Symptoms Store. Paul: from the point of view of interoperability maybe it is better to increase the flexibility of existing roles instead of adding a new one.

Types Store: would anyone use it decoupled from the Catalogue? Types are strongly linked to Syndromes and Protocols so maybe they are meant to be in the same entity/store. Alvin: believes it should be kept separate architecturally.

Jeff: we may have to define first class entities for Prescription and Symptom types because we may need more things defined along with them, e.g. content schema for symptoms, arguments for prescriptions etc.

We cannot safely detect existing symptom types by scanning the symptoms store because some symptoms type instances may have not been emitted yet (e.g. if they're rare or if building a SAF from scratch). Jeff: we could also make use of schemas instead of trying to determine this from the symptoms store.

Jeff: symptom emitters register once with the types store and then just emit symptoms. Paul: doesn't agree cause this violates the "dumb" emitters principle. Symptom emitters should not even know the existence of such stores.

Jeff: if we focus on Prescription we can see that such a types store is very helpful in defining Protocols by knowing the parameters/arguments needed to construct Prescriptions (and hence writing the directive properly). Paul argues that this is possibly out of scope: how authors write their Protocols should not be of concern to SAF users. However, if this is about interoperability of authoring tools then the Types Store makes sense, as it would help the ecosystem to grow.

Paul: before we commit to using a Types Store we should have a look at existing standards so that we avoid duplication. A similar sounding "knowledge repository" standard under OMG seemed particularly complex and doesn't probably constitute prior art.

Vivian: Types Store makes more sense if it is to hold all types (and "metadata") for all SAF elements (i.e. Symptoms, Syndromes, Protocols, Prescriptions)

Types store is to promote collaborative and authoring tools. Without it domain experts would have to use out-of-SAF means to exchange knowledge and build a SAF system. It will probably be logically separated from Symptoms store and Catalogue because it may be federated and used in different ways than those

> Types Registry
> --------------
>
>                 Key: SAF-16
>                 URL: http://tools.oasis-open.org/issues/browse/SAF-16
>             Project: OASIS Symptoms Automation Framework (SAF) TC
>          Issue Type: Task
>            Reporter: Jeffrey Vaught
>            Assignee: Jeffrey Vaught
>            Priority: Critical
>
> Introduce a Registry information source for Prescription Types & Symptom Types.  Also provide entities for PrescriptionType & SymptomType.  These would assist a Catalog author in creating syndromes & protocols w/o requiring historic symptoms/prescriptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira