[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]