[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saf] Spec changes
See
inline… From:
Stavros.Isaiadis@uk.fujitsu.com [mailto:Stavros.Isaiadis@uk.fujitsu.com] Hi again, Some changes I propose for the main spec based on our recent
discussions: -
CatalogueSource -> CatalogueEditor (or something
that denotes the more fine grained control) Jeff –
makes sense. -
Case Manager -> remove? We have no real use for a
Case Manager in the spec and certainly not in our implementation. I think this
is redundant unless we consider adding "Case" as well as a concept
–which might complicate things. Jeff – Case
Manager is an Orchestrator, and seems to be implementation specific. -
Add TypeRegistry –maybe with a better name? Also, this
by no means mandates the actual existence of a registry in the system, but
simply a point where users can find existing types. How this is to be
implemented is a detail out of the spec (e.g. could be implemented as an actual
registry/store, or as a query mechanism that collects this information from the
various places in the framework). Jeff – Why
wouldn’t the Catalog be a good place to store the Type information? Answering
my own question: Architecturally, it is probably best to separate
Practitioner/SymptomEmitter registered information from CatalogEditor supplied
information. In an implementation, a single data store could be used for both
(simplifying administration, maintenance, etc). Does that sound about right? -
I have some issues with the interfaces as set out in
the spec. "Interfaces" imply specific interaction semantics, and the
way they are currently spelled out makes me uncomfortable. In a sense, what we
have there are not interfaces, but Roles! But we already have the term role for
the active roles in the framework, so this makes things tricky (imagine:
"The role of SymptomHandler can be taken by the role of
Diagnostician" :-\ ) And these roles have some operations which we should
spell out not in the common format ("getPrescriptionTypes" etc) but
in a more loose way ("get/list prescription types"). Then in the
relevant appendix we make it more concrete with specificities, e.g. REST. Jeff – I think the first column in our Interface table
is just the ‘name’ of the Interface, not a role. For example, SymptomHandler
is not a role, but just the name of an interface. Agree that the operations
should be defined in a loose way. Thoughts? If we can agree on some of these, I can start editing the
main spec. Cheers, Stavros -- Fujitsu
Laboratories of Europe
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]