OASIS Emergency Management TC

 View Only

  • 1.  DE Conformance

    Posted 04-28-2010 13:28 
    



    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 list{lat,<space>lon<space>}
    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


Related Content