Roger copy. From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, May 17, 2010 8:44 PM
To: McGarry, Donald P.
Cc: 'emergency@lists.oasis-open.org'
Subject: RE: [emergency] OASIS HAVE - lessons learned - flexible adaptive approach needed My time is really spread thin right now. I've very leary of getting into too low level angle brackets time sink until people understand the concepts overall. I've been burnt on this before. Once the concepts are clear other people can fill in the lowlevel details from their use cases. -------- Original Message --------
Subject: Re: [emergency] OASIS HAVE - lessons learned - flexible
adaptive approach needed
From: "McGarry, Donald P." <dmcgarry@mitre.org>
Date: Mon, May 17, 2010 1:25 pm
To: "'david@drrw.info'" <david@drrw.info>
Cc: "'emergency@lists.oasis-open.org'" <emergency@lists.oasis-open.org> David-
I guess I'm looking for a more real-world system level example as to how this would be implemented in terms of EDXL. Is that something that you could provide?
Thanks!
Don McGarry
The MITRE Corp.
dmcgarry@mitre.org
(315) 838-2669 Office
(703) 595-9375 Cell
Sent via Blackberry
From: David RR Webber (XML) <david@drrw.info>
To: McGarry, Donald P.
Cc: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
Sent: Mon May 17 11:23:50 2010
Subject: RE: [emergency] OASIS HAVE - lessons learned - flexible adaptive approach needed Don't confuse tool with standard. I have xslt that does CAM approach - and much of toolkit is written in xslt. It would work just as well in Python, Javascript, etc, etc - its the approach that is important - not the implementation language. The power of using declarative approach is exactly that - removing the need to write custom code!!! That was IBM's reason for using CAM - they can script the desired behaviour in XML and that is dynamic and flexible. At OASIS we can take a lead in showing people how to truly exploit the power that XML technologies bring - or we can continue to slavishly follow only what the W3C says is good for you - and yet that has been shown to not provide the desired results particularly in highly agile and adaptive scenarios - e.g. emergency response needs. For example - it would be entirely possible to build templates that handle variant XML - that they have never encountered before (that is what IBM are doing with the automotive part orders) - and not fail - but continue to reliable process that content. Using XSLT or Javascript processing handles that beautifully - not just Java based SDOM processing. It's all about the approach. Now - what we are also working on in CAM is the canonical XML dictionary - which opens up another level of adaptive components - where definitions are shared that way. W3C explicitly says dictionaries and registries are a bad thing and should not be used - only Schema - that is Tim Berners-Lee's position - but that was before cloud computing - and he was thinking only in terms of the then web infrastructure. Innovation now could make a radical difference in how people can handle future emergency challenges in the real world. -------- Original Message --------
Subject: RE: [emergency] OASIS HAVE - lessons learned - flexible
adaptive approach needed
From: "McGarry, Donald P." <dmcgarry@mitre.org>
Date: Mon, May 17, 2010 10:28 am
To: "David RR Webber (XML)" <david@drrw.info>,
"emergency@lists.oasis-open.org" <emergency@lists.oasis-open.org> I don’t quite follow a few of your thoughts… 1. Regardless of the location hospital status is a fairly static object. Hospitals offer services that have availability and capacity. They also contain resources / supplies that have a count. 2. Building our standard around the CAM tool requires dictates or implies the use of Java. I don’t this we should be tying our standards to specific implementation technologies. 3. I appreciate that the CAM tool can handle validation and XML processing beyond that of a schema alone, but I’m unclear how it would eliminate the need for custom code beyond passing XML documents around. I.e. if I want to route data for hospitals that has Emergency Department Status == Open, I need to write custom code for that. That requires me to write code to implement part or all of the HAVE standard. From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, May 17, 2010 10:06 AM
To: emergency@lists.oasis-open.org
Subject: [emergency] OASIS HAVE - lessons learned - flexible adaptive approach needed Along with the recent submission from HHS submission and revisiting here on the analysis from Haiti - there appears to be a gap between the HHS analysis and this. The lesson here is clear - what is needed instead of a fixed static Schema XSD is a more flexible adaptive approach to allow future disaster support needs to adapt on the fly. Example - Haiti hot and tropical - what if the disaster is in frozen area - like Iceland, or a desert area in Africa? Fortunately OASIS already has an answer here - and IBM have demonstrated its usefulness in providing a flexible XML validation framework: So - the question is - we can build a dictionary driven adaptive approach for HAVE v3 that allows extensions to be easily and quickly added without breaking messaging services - and base that on existing OASIS standards - so how do we get there? -------- Original Message --------
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs.
Released Schemas
From: "Lee Tincher" <ltincher@evotecinc.com>
Date: Mon, March 15, 2010 9:34 am
To: "'Dwarkanath, Sukumar - INTL'" <Sukumar_Dwarkanath@sra.com>,
<dmcgarry@mitre.org>, <emergency@lists.oasis-open.org>
Cc: "'Lewis Leinenweber'" <lleinenweber@evotecinc.com> 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… 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
From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Sunday, March 14, 2010 4:54 PM
To: Lee Tincher; 'Dwarkanath, Sukumar - INTL'; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
It’s not that you MUST use every element/attribute, but the fact that you CAN. Too much flexibility leads to more lines of code to process parts of a message that MAY be there, but probably never will. We are only using xPIL for a standard representation of the parts that we need. I don’t think we need the entire xPIL spec, and I think it makes HAVE bloated by including a bunch of optional stuff that is unnecessary. You can restrict the schema by modifying it without breaking it, you just use what you need and remove the rest. Since everything in xPIL is optional this isn’t a problem.
On the point of #5…you don’t NEED every aspect of xPIL to get HAVE…and it’s not about validating…my example validates too. The point of the example is to show what happens when someone fills in all the possible fields in a message. If you are building the system that processes one of these messages (not just putting it up on a webpage) you need to write code to handle all those fields. I think that’s bloated and unnecessary for what HAVE is trying to do.
-Don
Office: 315-838-2669
Cell: 315-383-1197
dmcgarry@mitre.org
From: Lee Tincher [mailto:ltincher@evotecinc.com]
Sent: Sunday, March 14, 2010 4:45 PM
To: McGarry, Donald P.; 'Dwarkanath, Sukumar - INTL'; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
I guess I don’t understand why including a full schema (which you would have to in order to achieve validity) means you have to use every element/attribute….
It seems that the flexibility intended by the optional elements and definitions of xPIL would be ignored if we did not include the schema….and I would think you can’t modify the Schema without breaking the standard unless you just included all of the mandatory elements and relationships and ignore the optional ones.
The #5 below is the hardest for me to absorb – why would you need every aspect of xPIL to get to HAVE? I have done thousands of HAVE exchanges without that problem… and they all validate…
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: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Sunday, March 14, 2010 4:26 PM
To: Lee Tincher; 'Dwarkanath, Sukumar - INTL'; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
Lee-
If you look at some of the later emails I sent out I would disagree. I don’t see an exchange scenario for HAVE where the CIQ elements not covered in the HAVE documentation are needed (Stock Information, Vehicle information, etc.) This was the result of copying the entire xPIL schema. Here is an excerpt of my issue:
1. Our documentation is not clear about using xPIL – It doesn’t constrain the use of xPIL or the use of lists.
2. We just bulk-copied the xPIL xsd and posted it along with HAVE
3. I don’t think someone writing code for EDXL-HAVE should have to write code to parse a Hospital’s stock ticker symbol
My original question was regarding
1. whether HAVE really intended to include the entire xPIL schema in the HAVE documents
2. Why the HAVE documentation didn’t match the included xPIL schema
3. Why we didn’t make some form of OrganizationInformation mandatory
4. I wonder if your HAVE system handle everything in the OrganizationInformation in my large sample HAVE message posted to KAVI without crashing and have the ability to reproduce it? I’m guessing that since our documentation totally glazes over the attributes, account, contact number, documents, electronicaddressidentifiers, events, memberships, relationships, recenues, stocks, and vehicles; and that there are numerous elements that can be represented as lists in there that aren’t covered in the HAVE documentation either that the answer may be no, which is not good for interoperability.
5. My sample files has 1982 lines of XML before you even get to the HAVE report. Is that what we really wanted?
-Don
Office: 315-838-2669
Cell: 315-383-1197
dmcgarry@mitre.org
From: Lee Tincher [mailto:ltincher@evotecinc.com]
Sent: Saturday, March 13, 2010 11:39 PM
To: 'Dwarkanath, Sukumar - INTL'; McGarry, Donald P.; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
There is no need for a CIQ profile as all optional elements and the extensions needed are for a specific exchange scenario. The idea of a profile is to define further constraints on optional elements and definitions as they apply to that intended exchange….so each profile that is based on a schema that includes CIQ (or any other import schema) would be different by it’s nature….
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: Tuesday, March 09, 2010 10:08 AM
To: McGarry, Donald P.; emergency@lists.oasis-open.org
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
Don,
The restrictions on using CIQ were considered to be business rules and the intention was not create a profile as far as I remember. I am not against creating a CIQ Profile but if we go down that path, we should consider requirements across the other standards such as EDXL RM, DE etc. We have dealt with this particular issue quite a few times and it is a balance – offering flexibility vs ensuring interoperability.
Sukumar
________________________________
From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Monday, March 08, 2010 8:31 AM
To: emergency@lists.oasis-open.org
Subject: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
All-
After spending some time doing some coding this weekend I noticed something that we may want to address:
1. HAVE uses xPil which in turn uses xAL and xNL
2. We included the full schemas for all of these referenced schemas on the OASIS page to download the standards.
I think the problem here is that when I went to implement this the documentation states that we are using a “profile” recommendation to limit the choices for xPil to “maximize interoperability”. It then goes on to state that <have:Organization> should have the sub-elements OrganizationInformation and OrginizationGeoLocation.
OrganizationInformation should have the sub-elements as defined in the CIQ standard:
· OrganisationName
· OrganisationInfo
· Addresses
· ContactNumbers
· CommentText
It also states that we won’t use georss but will use the gml in the OrganizationGeoLocation Section.
It also refers me to Appendix C which suggests that I refer to the CIQ TC website, and also states that for the purpose of HAVE the naming & location elements are used. The use of other elements is left to implementation choices.
Conformance is defined in the document as:
1. Validating to the schema
2. Meets the mandatory requirements of section 3
My concern is that the referenced xPil schemas (and in turn the xAL and xNL) are the FULL SCHEMAS. There is no restriction in the HAVE schema enforcing our smaller profile of CIQ. Additionally the reference to the georss namespace or elements was not removed. Furthermore, the document is somewhat confusing in that it states what elements to use, but then tells the develop that it’s an implementation choice whether to use the other elements or not. Right now as it stands I can generate an XML document that has a bunch of xPIL fields that we didn’t include in our documentation, but will validate against our schemas. With the vagueness in the document I could argue that this was an implementation choice and my document is valid according to the conformance section, but I suspect my document may break some systems.
So which is it? If I am building an XML processor to ingest HAVE documents I need to know what to expect. If I need to be prepared to handle Accounts, Documents, Revenues, Stocks, etc. as defined in xPIL because some system out there decided that they wanted to do it, that makes HAVE more heavyweight that I think the designers intended. If indeed we are using a CIQ “profile” we should develop the schema for that profile and post it with the standard and add some more info to our documentation so it isn’t as vague. I’ll upload my generated sample file as HAVE_FullToSchemaButNotDocument.xml to the TC page so you can check it out. This example validated against the schemas from our page. I added in Geo-RSS as well (which will validate if you reference the georss schema)…
Don McGarry
Office: 315-838-2669
Cell: 315-383-1197
dmcgarry@mitre.org
|