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.
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?
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
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
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