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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-adopt message

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


Subject: DE Conformance


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

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

 




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