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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas


Thanks Tim,

I've been staying out of this particular discussion for a variety of 
reasons, but it is good to reiterate the basic situation once in a while.

Our standards are intended to be flexible, but there are limits even to 
flexibility, so such conversations are good for us all to air out our 
views on what our limits are.

Cheers,
Rex

Timothy Grapes wrote:
>
> David et al,
>
> Just to comment on NIEM compliance, Don is basically correct. OASIS 
> is an international standards organization which cannot be constrained 
> by any single national effort from any nation. Now, we have and 
> continue to work very closely with NIEM to increase consistency, 
> coordination and re-use. At the very least, each EDXL standard is 
> NIEM compliant by virtue of putting a NIEM adaptor in place for each 
> EDXL standard. In these cases the EDXL standards drive compliance, 
> and NIEM is not meant to “recreate†an existing external standard.
>
> In addition, the EM domain co-managed by S&T and FEMA leveraging their 
> formidable practitioner communities, continue to work with NIEM to 
> forward the cause for EDXL re-use of NIEM elements where appropriate 
> as new standards are developed, and also to add EDXL elements to the 
> NIEM EM domain to increase re-use value in NIEM (but again, NOT for 
> the purpose of every re-creating an external standard through a NIEM 
> IEPD).
>
> Finally, the ValueListURN serves the existing situation, allowing 
> groups of exchange partners to agree on their own code lists etc. and 
> leverage interoperability across their jurisdictions. It is 
> understood that different efforts may choose to enlist different value 
> lists, but it’s a trade-off between this and the fact that no one is 
> far enough along to gain global agreement in all cases.
>
> */Thanks,/**//*
>
> */Tim Grapes/*
>
> */Evotec/*
>
> "The only thing we take into the next life is our character"
>
> *From:* McGarry, Donald P. [mailto:dmcgarry@mitre.org]
> *Sent:* Monday, March 15, 2010 12:11 PM
> *To:* David RR Webber (XML); Lee Tincher
> *Cc:* 'Lewis Leinenweber'; 'Dwarkanath,Sukumar - INTL'; 
> emergency@lists.oasis-open.org
> *Subject:* RE: [emergency] HAVE Conformance vs. Documentation vs. 
> Released Schemas
>
> 1. Althogh NIEM compliance is “niceâ€â€¦we are building 
> International Standards here…and should not be NIEM-centric
>
> 2. The any namespace may be good for extensibility…but it is not 
> good for actually being able to process the XML data. Using any 
> creates yet another scenario where we need a developer pow-wow ahead 
> of time. This is not a model we should be striving to. A system should 
> be able to *process* (not just read) all fields of the standards that 
> we produce. Use of any tags are good for signature type things and 
> other implementation specific elements that have no bearing on the 
> data in the message whatsoever…or they are good for doing debugging 
> to determine what fields to add in the next version of the standard. 
> Looks like that is what Lee has done for us here.
>
> 3. Over-use of any moves to the model of a computer as a telephone 
> rather than as a processing engine….
>
> -Don
>
> Office: 315-838-2669
>
> Cell: 315-383-1197
>
> dmcgarry@mitre.org <mailto:dmcgarry@mitre.org>
>
> *From:* David RR Webber (XML) [mailto:david@drrw.info]
> *Sent:* Monday, March 15, 2010 12:04 PM
> *To:* Lee Tincher
> *Cc:* 'Lewis Leinenweber'; 'Dwarkanath,Sukumar - INTL'; McGarry, 
> Donald P.; emergency@lists.oasis-open.org
> *Subject:* RE: [emergency] HAVE Conformance vs. Documentation vs. 
> Released Schemas
>
> Lee,
>
> <ParameterName> <Value> keyword concept
>
> That is definitely not NIEM compliant nor is it good for long term 
> interoperability. Better is an extensible payload area with type of 
> ##any - or even better using the NIEM extension mechanism to provide 
> an extension schema for these new pieces. Those can then be simply 
> incorporated in the next standard schema.
>
> HAVE EDXL is a half-way house at the moment - some parts are following 
> NIEM - others not so much.
>
> Obviously its a balancing act - but I would suggest where NIEM has 
> good mechanisms for implementing these needs - that those techniques 
> should be considered first. This also allows just to provide 
> guidelines to developers - that then can then use when they encounter 
> these situations.
>
> Thanks, DW
>
>     -------- Original Message --------
>     Subject: RE: [emergency] HAVE Conformance vs. Documentation vs.
>     Released Schemas
>     From: "Lee Tincher" <ltincher@evotecinc.com
>     <mailto:ltincher@evotecinc.com>>
>     Date: Mon, March 15, 2010 9:34 am
>     To: "'Dwarkanath, Sukumar - INTL'" <Sukumar_Dwarkanath@sra.com
>     <mailto:Sukumar_Dwarkanath@sra.com>>,
>     <dmcgarry@mitre.org <mailto:dmcgarry@mitre.org>>,
>     <emergency@lists.oasis-open.org
>     <mailto:emergency@lists.oasis-open.org>>
>     Cc: "'Lewis Leinenweber'" <lleinenweber@evotecinc.com
>     <mailto:lleinenweber@evotecinc.com>>
>
>     Sukumar,
>
>     That’s exactly what we did (with an interspersing of <comment>
>     tags as well)…The problem is in the definition of the Value Name
>     vs. the Value – we just used an “=†sign – but that means
>     coders have more work to do outside of XML Parsers.
>
>     The <ParameterName> <Value> keyword concept used in CAP, DE, RM
>     and SitReps would have been much easier to deal with…maybe a
>     consideration for the next release?
>
>     I have attached the DRAFT that we have been using – it is only a
>     Draft so please do not pass this around outside of OASIS….it
>     includes a sample XML at the end…
>
>     Thanks,
>     Lee
>
>     /The aim of education should be to teach us rather how to think,
>     than what to think - rather to improve our minds, so as to enable
>     us to think for ourselves, than to load the memory with thoughts
>     of other men. ~Bill Beattie/
>
>     *From:* Dwarkanath, Sukumar - INTL
>     [mailto:Sukumar_Dwarkanath@sra.com]
>     *Sent:* Monday, March 15, 2010 8:51 AM
>     *To:* ltincher@evotecinc.com; dmcgarry@mitre.org;
>     emergency@lists.oasis-open.org
>     *Subject:* Re: [emergency] HAVE Conformance vs. Documentation vs.
>     Released Schemas
>
>     Lee,
>
>     This is good feedback and will be helpful - I am sure you have
>     already looked at it, but ResourcesInformationText was added as a
>     flexible alternative and can be used for most of the items in the
>     short term.
>
>     Thanks
>     Sukumar
>
>
>     -----Original Message-----
>     From: Lee Tincher <ltincher@evotecinc.com>
>     To: 'McGarry, Donald P.' <dmcgarry@mitre.org>; Dwarkanath, Sukumar
>     - INTL; emergency@lists.oasis-open.org
>     <emergency@lists.oasis-open.org>
>     Sent: Sun Mar 14 17:22:17 2010
>     Subject: RE: [emergency] HAVE Conformance vs. Documentation vs.
>     Released Schemas
>
>     Slightly off topic – but I think relevant to this discussion…I
>     would like to see some placements of the “keyword†concept
>     into HAVE to better handle extension of existing lists and ability
>     of new Managed Lists. Below is a bulleted list of items we found
>     necessary to support the Haiti Relief efforts…another problem is
>     that in a disaster we are primarily dealing with “Health
>     Facilities†and not just Hospitals (e.g. Clinics,
>     Damaged/Partially operating facilities, Tent or MASH style units,
>     converted elderly care facilities….)
>
>
>
>     In addition specific desires for information not included in the
>     HAVE specification was determined. These included:
>
>
>
>     · Information Blood Products
>
>     · Information on Ancillary Services
>
>     · Information on Laboratory Services
>
>     · Information on Pharmacy Services
>
>     · Status and capacity information on Rehab Services
>
>     · Accessibility by Road
>
>     · 24/7 Emergency Room capabilities
>
>     · Adult Ventilator capabilities and availability
>
>     · Pediatric Ventilator capabilities and availability
>
>     · General Medicine capabilities
>
>     · Is there adequate Nursing staff?
>
>     · Number of available skilled Nurses
>
>     · Are there adequate Medical Providers (available physicians and
>     mid-level)?
>
>     · Number of available Medical Providers
>
>     · Are there adequate Surgical Teams?
>
>     · Number of available Surgical Teams
>
>     · Structural Damage?
>
>     · Water Shortage?
>
>     · Power Shortage?
>
>     · Comments on demographic information
>
>     · Previously reported demographics information is confirmed?
>
>     · Internet Access Available?
>
>     · Email Available?
>
>     · Phone Service Available?
>
>
>
>     In addition further restrictions apply to the following HAVE elements:
>
>
>
>     · HospitalStatus/Hospital/Organization/Addresses this is free
>     text, but to specify the the "Seccion Communal" use "Seccion=
>     [Name of Seccion Communal]"
>
>     ·
>     HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/AdministrativeArea/SubAdministrativeArea
>     Use "Commune= [Commune Name]"
>
>     ·
>     HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/AdministrativeArea/SubAdministrativeArea
>     Use "Arrondissement= [Arrondissement Name]"
>
>     ·
>     HospitalStatus/Hospital/Organization/OrganizationInformation/Addresses/AdministrativeArea/NameElement
>     "[Department Name]"
>
>     ·
>     HospitalStatus/Hospital/Organization/OrganizationGeoLocation/gml:point/gml:pos
>     restricted to 4 decimal places
>
>
>
>     Thanks,
>
>     Lee
>
>
>
>     The aim of education should be to teach us rather how to think,
>     than what to think - rather to improve our minds, so as to enable
>     us to think for ourselves, than to load the memory with thoughts
>     of other men. ~Bill Beattie
>

-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670



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