Input for Nov 3 notes

Friends,

Please note the details Patti provided for our notes from the meeting 11/3. During our call today, I will invite you to consider these as updates to the draft notes posted for this meeting.

Best,

Elysa

TAB Comment: “Extract and list "additional mandatory requirements" that are not reflected and enforced by the XSD schema.”

TC Resolution: Add comment to Conformance section stating that the additional mandatory requirements are detailed in the data dictionary.

TAB Comment: “Note that urn:oasis:names:tc:emergency:edxl:tep:1.0, should be written as: urn:oasis:names:tc:emergency:edxl:1.0:tep in both clauses.”

TC Resolution: The change would imply that the version is on EDXL rather than on the specific specification (e.g., TEP). This is consistent with all EDXL specifications. The namespace declaration will be left, as is.

TAB Comment: “3.2.3 EDXL Extensions Note that this mechanism should be used only for required elements – if an element is optional, it could be completely replaced by any community extension, with its own name and structure.”

TC Resolution: The intent of the TC is to allow users to completely replace the element by any community extension, with its own name and structure. The specification will be left, as is.

TAB Comment: “Check and correct "shall" to MUST as appropriate.”

TC Resolution: This is consistent across EDXL specifications. The specification will be left, as is.

TAB Comment: “I would delete all the [1...1] notations, etc. and if you want to describe a co-occurrence constraint that you can't in the schema, fine. But let's not invent notation for stuff already covered in the schema.”

TC Resolution: This data dictionary notation is consistent across the EDXL specifications and useful for implementers. The specification will be left, as is.

TAB Comment: “delete from all the element definitions: "REQUIRED;”

TC Resolution: This data dictionary notation is consistent across the EDXL specifications and useful for implementers. The specification will be left, as is.

TAB Comment: “It is sufficient to state the constraint without the "CONDITIONAL" keyword, thus: Delete: 1.4 "In addition, within this Specification, the keyword “CONDITIONAL” should be interpreted as potentially “REQUIRED” or “OPTIONAL” depending on the surrounding context."

TC Resolution: This data dictionary notation is consistent across the EDXL specifications and useful for implementers. The specification will be left, as is.

emergency message