I added some text at http://tools.oasis-open.org/issues/browse/SAF-16 that could go in the spec. Let’s discuss in the call in a while. Thanks, Stavros From: Isaiadis, Stavros
Sent: 25 July 2011 09:44
To: saf@lists.oasis-open.org
Subject: [saf] Call today “Types Store might include semantic information, e.g. schema for the Symptom content, and arguments for Prescription Types, as this is going to 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” Let’s focus on this today and keep it simple. We will start with any potential updates from the previous discussed issues. Is there anything else you want to discuss?
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.
References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
|