EDXL_DE_modifications_050818

A   DONE in SCHEMA, SPEC
New Issue: <distributionReference>, should be comma delimited (not
delimited with colons).
Reason: colons conflict with MACID or other senderID types content and
thus make parsing the string difficult.
Proposal: use commas as delimiters
Action: Change <distributionReference> Comments, and example in
documentation. (Michelle)


B   DONE in SCHEMA, SPEC
Issue 7: <senderID> definition should be more generic as is <explicitAddress>
Originator: Kon Wilms
Proposal: change to:
       Definition:  The unique identifier of the sender.
       Comments:  Uniquely identifies human parties, systems, services, or
       devices that are all potential senders of the distribution message.
Discussion: The <senderID> is a string and could be in any format if
not structured as in the existing comments to have the form
sender@domain-name.
Proposal: Add the Comment suggested by Kon and leave the rest of the
comment as is.
Action: Add to <senderID> Comment.
Related Action (from Issue 6): Put in a valid MAC ID example (Michelle)
0006.0e39.ad80@petroplant


C    DONE in SCHEMA   SPEC
Issue 8: Add a scoping element to disambiguate <explicitAddress> schemes
Originator: Art Botterell
Discussion: This needs to be done.  It can be done as an attribute or
a container.
Proposal: change to container structure:
       <explicitAddress> *
               <explicitAddressScheme> 1 <--- type = xsd:string  def:
use examples
- email, USMTF (for military use) , etc...
               <explicitAddressValue>  + (--- type = xsd:string
       </explicitAddress>
Action: Modify Schema (Dave), Modify Spec (Michelle),  Modify chm (Sylvia)


D   DONE in SCHEMA    SPEC
Global Note: all strings as values of elements should not break an XML parser.
Action: Make a note of this in the specification. ()


E   DONE in SPEC  
New Issue: Some of the content of the Examples is close to issues of
IP and Sensitivity of information
Action: Remove Appendix A: Examples (Michelle)

E'
Action: Add non-normative reference to the cookbook draft (Julie to
supply pointer)


F  DONE in SCHEMA   SPEC
Issue 3: restructure <contentObject>
originator: Michelle Raymond (based on emails and live discussions)
Discussion: Considered different structures and which elements were
only for xml or non-xml content.
Proposal:
<contentObject> *
      <contentDescription>
      <contentKeyword> *
      <originatorRole> *
      <consumerRole> *
      <confidentiality>
      {choice} 1
              <nonXMLContent>      <- (mimetype restr documented in header)
                      <mimeType> 1 (REQUIRED)
                      <size>
                      <digest>
                      <uri>
                      <derefUri>
              </nonXMLContent>
              <xmlContent> (namespace here)
                      <keyXMLContent>
                      <embeddedXMLContent>
              <xmlContent>
</contentObject>

Action: Modify Schema (Dave), Modify Spec (Michelle),  Modify chm (Sylvia)

F'
Action: Put in mimeType restriction documentation at the
<nonXMLContent> level. (Michelle)

Action: Reword introduction to Section 3.2.3 contentObject Element and
Sub-element. (Michelle)


G
Action: Once Schema is restructured, check and revise documentation.



H  
Action: Convert a current version of the Specification into Word and
check it in. (Michelle) 


I  DONE in  SCHEMA   SPEC 
New Issue: Should Section 1.6 have references to ISO-8601 format for
DateTime, ISO 3166-1 and 2 and UN/LOCODE used in the targetArea
container element?
Originator: Dave Ellis
Discussion: W3C XML Schema Part 2 best captures our constraints.
Action: Leave the Normative Refs. as is.
Action: "Change <dateTimeSent> Comment 2. text to: Must be in the W3C
format for the XML [DateTime] data type." (Michelle)
Action: Link [dateTime] to appropriate item in the Normative Refs
section. (Michelle)
----------------------------------------------------------------------

J
New Issue: Rename <derefUri>
originator:Renato Iannella
Rationale: The element name is not related to the semantics of its content (and
hence misleading) It is not a 'de-referenced URI" - it is the actual
base64 content data.
Suggestion: Change <derefUri> to <contentData>.




K
New Issue: Rename <valueListUrn> 
Originator: Renato Iannella
Rationale: The element name is not related to the semantics of its content (and
hence misleading.) It does not contain a URN.
Suggestion: Change <valueListUrn> to <valueScheme>



L
New Issue: Change type of <senderID>
Originator: Renato Iannella
Rationale: Would be more generic than the sender@domain-name format.
Suggestion: Change type from "xsd:string" to "xsd:anyUri"