| Please remember that observers are not allowed to post and their feedback must be submitted through the TC comment list (which requires their consent to the OASIS feedback license). Emails from non TC members should not be forwarded to the list.
Regards,
Mary
On Jun 23, 2010, at 5:25 AM, < Stavros.Isaiadis@uk.fujitsu.com> < Stavros.Isaiadis@uk.fujitsu.com> wrote:
Mary P McRae Director, Standards Development Technical Committee Administrator OASIS: Advancing open standards for the information society twitter: @fiberartisan #oasisopen phone: 1.603.232.9090
Standards are like parachutes: they work best when they're open.
Hi all, Forwarding an email from Roger, our colleague at FLE (it seems he cannot send emails to the list because he is an observer). From: Roger Menday [mailto:roger.menday@uk.fujitsu.com]
Sent: 23 June 2010 09:52
To: Dave Snelling
Cc: Stavros Isaiadis; saf@lists.oasis-open.org
Subject: Re: [*SPAM?*] Re: [saf] Spec changes On 22 Jun 2010, at 14:39, David Snelling wrote: - 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. Just a thought : you might choose to see Types as something slightly more dynamic. For example, I can imagine trending Symptom types - pretty much like a trending topic on Twitter. p.s. for others in the group, I am working with Dave/Stavros/Vivian. I've just started to lurk. 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. |
Senior Researcher, Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
Tel: +44 (0) 208 606 4534 ______________________________________________________________________
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. |
|