RE: [emergency] DE Conformance

["McGarry, Donald P." <dmcgarry@mitre.org>]

Gary-

I agree 100% with both.  Only reason I added the extra space is that in the circle example in the documentation there is a space between lat and lon.  I will update the spreadsheet to reflect these changes unless anyone objects and upload the DE2.0 spec document as well with mirror some of these points.

 

-Don

Office: 315-838-2669

Cell: 315-383-1197

dmcgarry@mitre.org

 

From: Gary Ham [mailto:gham@grandpaham.com]
Sent: Wednesday, April 28, 2010 10:33 AM
To: McGarry, Donald P.
Cc: emergency@lists.oasis-open.org; emergency-adopt@lists.oasis-open.org
Subject: Re: [emergency] DE Conformance

 

I see two differences:

 

circle:         lat,<space>lon<space>radius   should be:     lat,lon<space> radius

Similarly 

polygon:    list{lat,<space>lon<space>}       should be:  list{lat,lon<space>}  except that the space is not required for the final entry

 

R/s

Gary

 

 

On Apr 28, 2010, at 9:27 AM, McGarry, Donald P. wrote:

All-

We addressed some good points in the IF-SC yesterday that I thought should be brought up offline to the TC…

While we were addressing other issues Dave ran some sample messages through CAM to do some validation & conformance evaluation.  My sample messages (which were generated from XMLSpy) didn’t specify a timezone or offset from UTC, which was discussed as a side item.  The DE schema uses the W3C standard DateTime Format, but then clearly states that the dateTimeSent element must include the offset time for time zone.  So this was mia culpa.  At the meeting the question was raised that if no offset is specified UTC is assumed.  I did a little digging and it turns out local time is assumed, which as stated in the ISO 8601 documentation introduces ambiguity. 

 

Thanks to Dave and the CAM tool for bringing out conformance to the forefront in a solid example.

Dave – Can you share your CAM tool configuration file with the TC ?

 

From the W3C standard site (http://www.w3.org/TR/xmlschema-2/#timeZonePermited)

“…The lexical representations for the datatypes date, gYearMonth, gMonthDay, gDay, gMonth and gYear permit an optional trailing time zone specificiation.”

W3C uses ISO 8601 for DateTime.  Their spec states that:

“If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. It is usually preferable to indicate a time zone (zone designator) using the standard’s notation.

 

After discussing this and a couple of other conformance issues for DE 2.0 I went through the document and pulled out all of the conformance points not covered in the schema to share with the TC.  Please look this over and comment / add to the list so we can have list that we agree is representative of the documentation.  I will then put this on the Adoption TC’s wiki section on implementing the standards so we have a public reference point.

 

Element Name	Schema Data Type	Restriction	Comments
senderID	string	In the form actor@domain-name	Is this only <string>’@’<string> Or should it be <string>’@’<string>'.'<string>
dateTimeSent	dateTime	The Date Time combination must include the offset time for time zone.
language	string	Valid language values are supplied in the ISO standard [RFC3066]	Are we limiting this to the primary two character language tag or are we allowing subtags?
distributionReference	string	Comma delimited string consisting of a valid dist. ID, senderID, and dateTimeSent
distributionReference	string	This element should appear at least once in any message which updates, cancels, or otherwise refers to another message.	We use the word SHOULD not MUST.  Does this need to be enforced for conformance?  If so should it be for distribution types Update, Cancel, Response, Ack, Error?
circle	string	In the form lat,<space>lon<space>radius	Lat/lon is WGS84.  Radius is in km
polygon	string	Must be a valid polygon.  Must be in the form
country	string	Two character ISO 3166-1 country code
subdivision	string	Iso3166-1’-‘char[3] subdivision code	Should be in the form char[2]’-‘char[3]
locCodeUN	string	Iso3166-1’-‘UNLOCCODE	Should be in the form char[2]’-‘char[3]
digest	string	Result of SHA-1 hash on payload data	So the result of the hash is just 160 bits.  Is the string encoded using ASCII / UTF-X / ???
keyXMLContent	string	Must be explicitly namespaced as defined in the closing contentobject block	Does this have to be valid XML?  I don’t think we want to namespace the entire contentobject block, but the actual data in the content.  I realize this can be done with a namespace declaration in the contentobject block with a prefix and then xml content in key/embedded can be prefixed.  Is this what we meant?
embeddedXMLContent	string	Same as above	Same as above

 

 

I will also save this table in an excel spreadsheet and post it to kavi.

Please provide input so we can move ahead with a solid set of conformance rules.

Thanks!

Don McGarry

The MITRE Corp.

Office: 315-838-2669

Cell: 315-383-1197

dmcgarry@mitre.org

 

---

 

 

Gary Ham

http://grandpaham.com

703-899-6241