OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] DE Conformance

I see two differences:

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


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

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 ?
“…The lexical representations for the datatypes dategYearMonthgMonthDaygDaygMonth 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
In the form actor@domain-name
Is this only <string>’@’<string>
Or should it be <string>’@’<string>'.'<string>
The Date Time combination must include the offset time for time zone.
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?
Comma delimited string consisting of a valid dist. ID, senderID, and dateTimeSent
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?
In the form lat,<space>lon<space>radius
Lat/lon is WGS84.  Radius is in km
Must be a valid polygon.  Must be in the form 
Two character ISO 3166-1 country code
Iso3166-1’-‘char[3] subdivision code
Should be in the form char[2]’-‘char[3]
Should be in the form char[2]’-‘char[3]
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 / ???
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?
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.
Don McGarry
The MITRE Corp.
Office: 315-838-2669
Cell: 315-383-1197

Gary Ham

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]