What you are proposing would cause two systems to come together in an emergency situation that were previously unanticipated as interacting agents, both built to a spec that would break. I don’t see how this would help save lives. XML was not designed for interchanges; it was designed for structured markup and representation of data. It’s easy to tout agility and flexibility until you have to write the code that can actually handle it. Bloated, heavyweight, and “flexbile” standards keep being developed and keep failing, while sleek, slim, well designed, and easily implementable standards thrive. Take the HL7 C32 for example. It’s so nice and flexible most IDE’s can’t even pull in the WSDL for it. The average C32 exchange takes about 10 transactions to complete so folks can “agree” on format. This doesn’t help in battle, it hinders. Especially on less than ideal connections, with disparate systems. Fixed XML isn’t brittle?!? Fixed XML is functioning quite well in the majority of operational systems out there. I’d love to see your operational system that can accept and magically process any XML data I can throw at it. If you want to just throw whatever data into a system, go use SOAP. Or if you think you can do better; go for it, start another TC. HAVE is about Hospital Availability. Forcing developers to write code to process a hospitals ID by its stock ticker symbol is useless. Allowing them to just plug whatever suits their fancy is also useless, because if we were going to do that we could just use SOAP and be done with it. Some degree of flexibility is already built into the standard by the ValueListURN and some structured extendible data elements. Lee was kind enough to share some operational feedback to combine with our efforts to update the spec. The EM-TC is not here to: 1. Make one big messaging system for the US 2. Reinvent SOAP 3. Make standards so bloated no one will use them 4. Make a standard so “flexible” that it needs a series of AI agents running on the backend to determine what data is coming into the system I reiterate again the point of my message: 1. The documentation doesn’t match the schema in regards to xPIL 2. I think we should use a standard EDXL xPIL profile because xPIL was designed to cover all bases with PIM info and we only need some of those 3. I was surprised that you can have a valid HAVE message with no Orgnizational or Geographical information at all -Don Office: 315-838-2669 Cell: 315-383-1197 dmcgarry@mitre.org From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, March 15, 2010 4:06 PM
To: Gary Ham
Cc: ltincher@evotecinc.com; 'Lewis Leinenweber'; 'Dwarkanath,Sukumar - INTL'; McGarry, Donald P.; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas Of course. But if its a shooting war I'd rather make sure we're saving peoples lives first - in a systematic way that is rapidly assimulatable - and that we have that available as an option and tooling supports. If the answer in an emergency is - well you can't do that because its not in the international schema - then IMHO that is totally the wrong answer. Change is constant - and agility should be built-in. That was the whole point of using XML in the first place to allow agile self-descriptive interchanges - instead of brittle fixed EDI. Instead we've ended up in a lot of cases with brittle fixed XML. Fortunately some folks are realizing the value of having contextual adaptive mechanisms. I guess the only thing that is the real driver here - is when you see those capabilities showing up in your competitors solutions. And no - the answer is not all just ValueListURNs. I think we've come full circle here. -------- Original Message --------
Subject: Re: [emergency] HAVE Conformance vs. Documentation vs.
Released Schemas
From: Gary Ham <gham@grandpaham.com>
Date: Mon, March 15, 2010 2:52 pm
To: David RR Webber (XML) <david@drrw.info>
Cc: ltincher@evotecinc.com, "'Lewis Leinenweber'"
<lleinenweber@evotecinc.com>, "'Dwarkanath,Sukumar - INTL'"
<sukumar_dwarkanath@sra.com>, dmcgarry@mitre.org,
emergency@lists.oasis-open.org What you are saying here is "fork the standard." What you have described here is an excellent way to build an IEPD from NIEM or another previously defined IEPD. It is even a good way to model a needed change to a standard exchange. But is is not a good way to implement a standard. Because it is a one off that actually violates the standard schema, you have created a non-standard implementation fork if you build an actual exchange in this fashion. If you are building a custom system to system exchange, there is nothing wrong with this. If, however, you are building a multi-system reusable structure, this should only be the first step in establishing a potential new schema for submission to a standards process. Otherwise implementing it is customization, and not standardization. Gary On Mar 15, 2010, at 1:30 PM, David RR Webber (XML) wrote:
OK - lets spell this out in technical terms of schema - ignore I ever mentioned NIEM. Here's what you do. In OASIS EDXL there is the HospitalResourcesStatus. Critically it is missing all the mission elements needed below for Haiti relief purposes. So what you do is create an extension schema - put in all those new components that you need urgently - then extend the definition of HospitalResourcesStatus to include those as additional choices. Import the extension schema into the OASIS EDXL XSD - and now you have what you need working - and you disseminate the extension schema for those systems that need to process the extended elements. You submit your extension schema to the TC as suggestion for inclusion in next release of EDXL. As a TC it is therefore beneficial to instruct people - here's how to extend our schema in a recommended way to meet emergency needs. Please provide that as feedback to us when you do. -------- Original Message --------
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs.
Released Schemas
From: ltincher@evotecinc.com
Date: Mon, March 15, 2010 1:19 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "Lee Tincher" <ltincher@evotecinc.com>, "'Lewis Leinenweber'"
<lleinenweber@evotecinc.com>, "'Dwarkanath,Sukumar - INTL'"
<sukumar_dwarkanath@sra.com>, dmcgarry@mitre.org,
emergency@lists.oasis-open.org
David,
Once again I am in a position to completely disagree with your statements.
The Keyword concept not only matches nicely with the NIEM NDR it also
completely supports the use of NIEM Code Lists IF YOU CHOOSE TO USE
THEM
..
EDXL is a series of INTERNATIONAL Standards. Federation with NIEM is nice
and I heavily support that every day for both FEMA and DHS but
Federation is NOT compliance. For more on this I once again would point
you to http://www.grandpaham.com for some interesting perspective on this.
The ideas of things like adapters and code lists (especially through the
use of keywords) support the federation of NIEM if you choose to use NIEM.
We are not in the position (or the desire) to re-make EDXL into NIEM
that does not support our International views.
We (I am speaking of my little company) utilize NIEM through the concepts
provided to consume EDXL through adapters and code lists. I would like to
promote the idea of using NIEMs data dictionary for future development
simply because it helps us get closer to common terms between our varying
standards but that is a discussion for a much broader group that
includes our international members
Thanks,
Lee
> Lee, 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"
> Date: Mon, March 15, 2010 9:34 am
> To: "'Dwarkanath, Sukumar - INTL'" ,
> ,
> Cc: "'Lewis Leinenweber'"
>
> #wmQuoteWrapper /* Font Definitions */ @font-face
> {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} #wmQuoteWrapper
> @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;}
> #wmQuoteWrapper @font-face {font-family:Georgia; panose-1:2 4 5 2 5 4
> 5 2 3 3;} #wmQuoteWrapper /* Style Definitions */ p.MsoNormal,
> #wmQuoteWrapper li.MsoNormal, #wmQuoteWrapper div.MsoNormal
> {margin:0in; margin-bottom:.0001pt; font-size:12.0pt;
> font-family:"Times New Roman","serif";} #wmQuoteWrapper a:link,
> #wmQuoteWrapper span.MsoHyperlink {mso-style-priority:99; color:blue;
> text-decoration:underline;} #wmQuoteWrapper a:visited, #wmQuoteWrapper
> span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple;
> text-decoration:underline;} #wmQuoteWrapper p {mso-style-priority:99;
> mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto;
> margin-left:0in; font-size:12.0pt; font-family:"Times New
> Roman","serif";} #wmQuoteWrapper span.EmailStyle18
> {mso-style-type:personal-reply; font-family:"Calibri","sans-serif";
> color:#1F497D;} #wmQuoteWrapper .MsoChpDefault
> {mso-style-type:export-only; font-size:10.0pt;} #wmQuoteWrapper @page
> Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}
> #wmQuoteWrapper div.Section1 {page:Section1;} Sukumar, Thatâs
> exactly what we did (with an interspersing of 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 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
> To: 'McGarry, Donald P.' ; Dwarkanath, Sukumar - INTL;
> 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
|