[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
That's exactly what the ValueListURN is for, David, Well, its actually for a number of other things, as well, but it is certainly used for this kind of thing at its most readily understandable level. Any list you care to use, as long as it is published (URN), and maintained (versioned as needed) can be used. Down the line, we expect that the necessity of maintaining these lists will convince folks in a given domain and or set of jurisdictions, sets of agencies, etc, to come together on standard lists that will converge to the smallest number of lists that is needed for the domain. In the meantime, we have something we can work with, without the hassle of trying to put together master lists. Cheers, Rex David RR Webber (XML) wrote: > Gary, > That of course is a horse of a different color. > What I'm seeing is that we don't want to use value pairs to capture > the type of structured information content below - which is properly > represented as reusable components. > We do not need to repeat the disasters of EDI Z-segments!!! > > Thanks, DW > > -------- Original Message -------- > Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. > Released Schemas > From: Gary Ham <gary.ham@eyestreet.com> > Date: Mon, March 15, 2010 12:42 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: Timothy Grapes <tgrapes@evotecinc.com>, Lewis Leinenweber > <lleinenweber@evotecinc.com>, "Dwarkanath,Sukumar - INTL" > <Sukumar_Dwarkanath@sra.com>, "emergency@lists.oasis-open.org" > <emergency@lists.oasis-open.org>, "McGarry,Donald P." > <dmcgarry@mitre.org>, Lee Tincher <ltincher@evotecinc.com> > > We DO like valuelist urn pairs!! > even better if they identify niem approved code lists. > > Sent from my iPhone > > On Mar 15, 2010, at 12:38 PM, "David RR Webber \(XML\)" > <david@drrw.info <mailto:david@drrw.info>> wrote: > >> Tim / Don, >> So we don't like ##any, and we don't like parameter value pairs - >> so what NIEM instructs on using schema extensions would appear to >> be the way to go. It's not like this is exclusive to NIEM - they >> are merely using what W3C schema provides. I'm not asking you to >> join the Catholic church here. >> And I'm talking about all these extension items below. That's >> some major new information needs - and is perfect as an interim >> extension schema with suitable namespace - edxl-extn: or similar. >> Instead of having to backdoor this stuff - there should be an >> approved method for doing this - whether you want to label that >> "OASIS", "NIEM" or "W3C" - better to set out what is expected. >> BTW - some of this - access by road - should be coverable via >> gml: details - providing GPS route from facility to nearest major >> road? >> >> Thanks, DW >> · 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? >> >> -------- Original Message -------- >> Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. >> Released Schemas >> From: "Timothy Grapes" <tgrapes@evotecinc.com >> <mailto:tgrapes@evotecinc.com>> >> Date: Mon, March 15, 2010 12:19 pm >> To: "'McGarry, Donald P.'" <dmcgarry@mitre.org >> <mailto:dmcgarry@mitre.org>>, "'David RR Webber >> (XML)'" <david@drrw.info <mailto:david@drrw.info>>, "'Lee >> Tincher'" <ltincher@evotecinc.com >> <mailto:ltincher@evotecinc.com>> >> Cc: "'Lewis Leinenweber'" <lleinenweber@evotecinc.com >> <mailto:lleinenweber@evotecinc.com>>, >> "'Dwarkanath,Sukumar - INTL'" <Sukumar_Dwarkanath@sra.com >> <mailto:Sukumar_Dwarkanath@sra.com>>, >> <emergency@lists.oasis-open.org >> <mailto:emergency@lists.oasis-open.org>> >> >> 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 >> <mailto: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 >> <mailto: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>mailto:Sukumar_Dwarkanath@sra.com] >> >> *Sent:* Monday, March 15, 2010 8:51 AM >> *To:* ltincher@evotecinc.com >> <mailto:ltincher@evotecinc.com>; dmcgarry@mitre.org >> <mailto:dmcgarry@mitre.org>; >> emergency@lists.oasis-open.org >> <mailto: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 >> <mailto:ltincher@evotecinc.com>> >> To: 'McGarry, Donald P.' <dmcgarry@mitre.org >> <mailto:dmcgarry@mitre.org>>; Dwarkanath, Sukumar - INTL; >> emergency@lists.oasis-open.org >> <mailto:emergency@lists.oasis-open.org> >> <emergency@lists.oasis-open.org >> <mailto: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 >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC >> that generates this mail. Follow this link to all your TCs in >> OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- 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]