Hi Dave,
How's Krakow? :-)
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.
What are the differences with
the Diagnostician? If the Case Manager is reduced to only forwarding stuff to
the Diagnostician, couldn't we just do without him?
The idea originally of having a
separate Case Manager was to possibly integrate several Diagnosticians with
different specialities. I'm not real worried one way or another, as it is not
normative in the spec and only serves to guide. It might be better to loose the
CM and just have on Diagnostician and then hint that more complex renderings of
the spec are possible.
OK, that makes some sense. In my mind, Diagnosticians can differ
only in terms of how sophisticated they're –from the SAF perspective,
they merely check Syndrome signatures from one or more Catalogues against the
Symptoms in one or more Symptom stores. Is that what you mean by "different
specialties"?
- 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?
Kind of agree. We should not
mandate implementations. We had a discussion with Dave about this, he might be
able to chip in, but generally, the Catalogue contains the
"knowledge" in your system in a sense. The symptom and prescription
types are building blocks but not really knowledge, so they should be kept
separately.
Basically you guys have the same
view I do. One could implement them as one thing, but generally I see the
catalogue as more dynamic that the TyeRegistry. I also like Stavros' knowledge
line of thinking. I would model them separately in the spec for these reasons.
Implementers are free to render it how they wish.
Good, so it seems we all (?) agree on this.
- 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.
Yes Jeff you are right here.
Yes I know it's the name of the interface as it is, but
conceptually it's something like a role: SymptomEmitter and PrescriptionEmitter
don't even have operations in them! Which means they're there simply to denote
that an entity in the system (e.g. Practitioner) has this specific
rights/permissions/role. Exact terminology is eluding me right now, but I hope
you guys understand what I mean...
A Role is an entity in the system
that may (or may not) implement certain Interfaces. It really is just that
simple. The Interfaces are normative and the role aren't.
I am still a bit uncomfortable, something bugs me here. What is
an Interface with no operations?
Cheers,
Stavros
--
Fujitsu Laboratories of Europe
If we can agree on some of
these, I can start editing the main spec.
Fujitsu Laboratories of Europe
______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan does not guarantee that it has not been intercepted or amended nor that it is virus-free. |
______________________________________________________________________ Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE Registered No. 4153469 This e-mail and any attachments are for the sole use of addressee(s) and may contain information which is privileged and confidential. Unauthorised use or copying for disclosure is strictly prohibited. The fact that this e-mail has been scanned by Trendmicro Interscan does not guarantee that it has not been intercepted or amended nor that it is virus-free. |
Dr. David
Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu
Laboratories of Europe Limited
______________________________________________________________________
Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469
This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan does not guarantee that
it has not been intercepted or amended nor that it is virus-free. |
|