[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: EDXL_DE - Notes from the meeting to help with minutes and issues list.
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]