EDXL_DE - Notes from the meeting to help with minutes and issues list.

[Michelle Raymond <michellearaymond@gmail.com>]

Julia,

Here again are my notes, attached and below.

- Michelle




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)


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)


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)
	

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


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)
Action: Add non-normative reference to the cookbook draft (Julie to
supply pointer)


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


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


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


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


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)


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)
	

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


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)
Action: Add non-normative reference to the cookbook draft (Julie to supply pointer)


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


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


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


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)