OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saf] Spec changes


Title: Re: [saf] Spec changes
Hi All,

Sorry for chipping in late. Just one comment on “CatalogueSource -> CatalogueEditor”, I think semantically CatalogueSource hints more where the knowledge base comes from, rather than who is maintain it – CatalogueEditor. CatalogueSource makes more sense from reading the whole paragraph as well.

Regards,
Vivian

On 22/06/2010 14:39, "David Snelling" <david.snelling@uk.fujitsu.com> wrote:

Stavros,

On 22 Jun 2010, at 15:05, Stavros Isaiadis wrote:

Hi Dave,
 
How's Krakow? :-)

Sunny. Vivian and I will head out for a walk shortly.


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"?

Yes. But there may be cases where the "knowledge" cannot be held entirely in the catalogue. In these cases that Diagnostician might also be specialized in other ways as well.


-
         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.

That's the plan.


-
         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...

Here are my terms:
 
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?

I see where you are struggling. Think of the operation-less interfaces as having to implement some client side capabilities, e.g. they make calls on the service operations of other interfaces. But your right "Interface" might not be the right term. "Interaction Pattern"?



Cheers,

Stavros

--
Fujitsu Laboratories of Europe

 
Thoughts?
 
If we can agree on some of these, I can start editing the main spec.
 
Cheers,

Stavros

--
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.

Take care:
 
    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe Limited
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE
    Reg. No. 4153469
 
    +44-7590-293439 (Mobile)
 
 

 

 
Take care:

    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe Limited
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE
    Reg. No. 4153469

    +44-7590-293439 (Mobile)



 

______________________________________________________________________
                                        
 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]