[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.
Julie, I've copied the notes below and included them in the attached file. All of the "PROCESS", "ISSUE" and "EDIT TASK" items were noted in the meeting except the third PROCESS note. That is simply, my suggestion as to how to facilitate communication. I would add, as I think Rex brought up, it would be good if we also prefaced the subjects of our emails as "EDXL_DE_ISSUE or the like. Best Regards, Michelle PROCESS: The documents would be clearer to differentiate as separate entries into KAVI. Suggestion: Name the documents by version numbers, "0.1", "0.2" ... Proposal: Put the file of the draft specification in KAVI as "EDXL_DE_Draft_V0.1.html" and add files as they are incremented rather than adding a revision to the existing KAVI entry. Action: Michelle will check in the first of these drafts and update them after each meeting this week with a new entry and version number. PROCESS: We need an official keeper of the issues. Suggestion: Rope in a volunteer to maintain a table of issues. Stuckee: Art (with backup support from those who volunteered on the call) PROCESS: We need to keep the types of material flowing through email and other forms of converse clear. Suggestion: Going forward, for ease of differentiation, in communications please note what is a content issue as "ISSUE:" , what is a document spiffing up or formatting goof as an "EDIT TASK:" and what is a point-of-proceess as "PROCESS". ISSUE: Use of multiple <value> elements in conjunction with a <valueListUrn> element, where the values are from the value list, should be supported. Originator: Dave Ellis Rational: This reduces the reuse of the container elements (<keyword>, <senderRole, <contentKeyword>, etc...) and the need to repeat the list name in each of these container copies. Example: <consumerRole> <valueListUrn>railway:sensor:hazamat:alertRecipient</value> <value>hazmat.northLine@goRail.com</value> <value>application/CAMEO/plumeReport.bat</value> <value>fireDepartment@centerCity.gov</value> </valueListUrn> </consumerRole> Suggestion: Allow multiple <value> elements with an associated <valueListUrn>. Proposal: Within the "container" elements (<keyword>, <senderRole, <contentKeyword>, etc...) require one-and-only-one <valueListUrn> element and one-or-more <value> elements. Also, make certain it is documented that each of the container elements could be used more-than-once. Action: Proposal accepted. Changes to be made in the schema and specification by Michelle. ISSUE: Add a <location> element to the <contentElement>. Originator: Dave Ellis Action: Dave to write up rational and proposal. ISSUE: A <choice> between <uri>, <derefUri> and <namespacedXMLContent> should not be forced in a <contentObject> element. Originator: Michelle Raymond Reasons: 1. The <uri> element may be desired in the same <contentObject> as one containing a <derefUri> element to direct to where the dereferenced document is held. 2. The <uri> element may also be desired in the same <contentObject> as one containing a <namespacedXMLContent> element to direct to where the XML document is held. Suggestion: Take out the <choice> element and set each of the three elements to attributes of minOccur="0" and maxOccur="1 . Side-effect: This does allow for a <contentObject> to not have any of the three element types as sub-elements. These seems ok, as sometimes the synopsis is all that needs to be communicated. Proposal: Several were mentioned (see action.) Action: Michelle to write up the potential proposals discussed. ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea> element is too generic. Originator: Michelle Raymond Reason: "location" has too broad of a potential meaning. Suggestion: Rename <location> to <locCode>. Proposal: Rename <location> to <locCodeUN>. Action: Proposal accepted. Changes to be made in the schema and specification by Michelle. ISSUE: <originatorRole> and <consumerRole> provide less confusion against <senderRole> and <recipientRole> but do not disambiguate clearly. Originator: Michelle Raymond Reason: ambiguity as to context is not available from the naming. Suggestions: Option 1: use <senderRole> and <recipientRole> in <EDXLDistribution> and use <messageOriginatorRole> and <messageConsumerRole> in <messageObject>. Option 2: use <distributionSenderRole> and <distributionRecipientRole> in <EDXLDistribtion> and use <contentOriginatorRole> and <contentConsumerRole> in <contentObject>. Proposal: Leave as is. Action: Leave as is. EDIT TASK 00: Review draft of Specification Stuckee: EVERYONE - provide issues with reasons and suggestions Stuckee: EVERYONE - note consistency issues in text, typos, formatting problems, quibbles and nits about document structure, etc. EDIT TASK 01: Get the [Document Identifier as per OASIS Artifact Naming Guidelines] Stuckee: Julia (Thu.) EDIT TASK 02: Get the [OASIS Document Number] Stuckee: Julia (Thu.) EDIT TASK 03: Add links to Chair and Editor company names Stuckee: Michelle (Thu.) EDIT TASK 04: Add [Comma-separated keyword listing] Stuckee: Sukamar (Thu.) EDIT TASK 05: Determine the OASIS Conceptual Topic Model Area - [Please refer to (link) for appropriate topic area]] Stuckee: Julia (Thu.) EDIT TASK 06: Put in reference to CAP 1.1 for related spec. Discussion: This should be 'related' as in an example of how the <namespacedXMLContent> may be used. EDIT TASK 07: Add more History. Stuckee: Tom (Thu.) EDIT TASK 08: Add or delete Example Usage Scenario Stuckee: Sukamar (Thu.) EDIT TASK 09: Check for consistent bolding and bracketing
PROCESS: The documents would be clearer to differentiate as separate entries into KAVI. Suggestion: Name the documents by version numbers, "0.1", "0.2" ... Proposal: Put the file of the draft specification in KAVI as "EDXL_DE_Draft_V0.1.html" and add files as they are incremented rather than adding a revision to the existing KAVI entry. Action: Michelle will check in the first of these drafts and update them after each meeting this week with a new entry and version number. PROCESS: We need an official keeper of the issues. Suggestion: Rope in a volunteer to maintain a table of issues. Stuckee: Art (with backup support from those who volunteered on the call) PROCESS: We need to keep the types of material flowing through email and other forms of converse clear. Suggestion: Going forward, for ease of differentiation, in communications please note what is a content issue as "ISSUE:" , what is a document spiffing up or formatting goof as an "EDIT TASK:" and what is a point-of-proceess as "PROCESS". ISSUE: Use of multiple <value> elements in conjunction with a <valueListUrn> element, where the values are from the value list, should be supported. Originator: Dave Ellis Rational: This reduces the reuse of the container elements (<keyword>, <senderRole, <contentKeyword>, etc...) and the need to repeat the list name in each of these container copies. Example: <consumerRole> <valueListUrn>railway:sensor:hazamat:alertRecipient</value> <value>hazmat.northLine@goRail.com</value> <value>application/CAMEO/plumeReport.bat</value> <value>fireDepartment@centerCity.gov</value> </valueListUrn> </consumerRole> Suggestion: Allow multiple <value> elements with an associated <valueListUrn>. Proposal: Within the "container" elements (<keyword>, <senderRole, <contentKeyword>, etc...) require one-and-only-one <valueListUrn> element and one-or-more <value> elements. Also, make certain it is documented that each of the container elements could be used more-than-once. Action: Proposal accepted. Changes to be made in the schema and specification by Michelle. ISSUE: Add a <location> element to the <contentElement>. Originator: Dave Ellis Action: Dave to write up rational and proposal. ISSUE: A <choice> between <uri>, <derefUri> and <namespacedXMLContent> should not be forced in a <contentObject> element. Originator: Michelle Raymond Reasons: 1. The <uri> element may be desired in the same <contentObject> as one containing a <derefUri> element to direct to where the dereferenced document is held. 2. The <uri> element may also be desired in the same <contentObject> as one containing a <namespacedXMLContent> element to direct to where the XML document is held. Suggestion: Take out the <choice> element and set each of the three elements to attributes of minOccur="0" and maxOccur="1 . Side-effect: This does allow for a <contentObject> to not have any of the three element types as sub-elements. These seems ok, as sometimes the synopsis is all that needs to be communicated. Proposal: Several were mentioned (see action.) Action: Michelle to write up the potential proposals discussed. ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea> element is too generic. Originator: Michelle Raymond Reason: "location" has too broad of a potential meaning. Suggestion: Rename <location> to <locCode>. Proposal: Rename <location> to <locCodeUN>. Action: Proposal accepted. Changes to be made in the schema and specification by Michelle. ISSUE: <originatorRole> and <consumerRole> provide less confusion against <senderRole> and <recipientRole> but do not disambiguate clearly. Originator: Michelle Raymond Reason: ambiguity as to context is not available from the naming. Suggestions: Option 1: use <senderRole> and <recipientRole> in <EDXLDistribution> and use <messageOriginatorRole> and <messageConsumerRole> in <messageObject>. Option 2: use <distributionSenderRole> and <distributionRecipientRole> in <EDXLDistribtion> and use <contentOriginatorRole> and <contentConsumerRole> in <contentObject>. Proposal: Leave as is. Action: Leave as is. EDIT TASK 00: Review draft of Specification Stuckee: EVERYONE - provide issues with reasons and suggestions Stuckee: EVERYONE - note consistency issues in text, typos, formatting problems, quibbles and nits about document structure, etc. EDIT TASK 01: Get the [Document Identifier as per OASIS Artifact Naming Guidelines] Stuckee: Julia (Thu.) EDIT TASK 02: Get the [OASIS Document Number] Stuckee: Julia (Thu.) EDIT TASK 03: Add links to Chair and Editor company names Stuckee: Michelle (Thu.) EDIT TASK 04: Add [Comma-separated keyword listing] Stuckee: Sukamar (Thu.) EDIT TASK 05: Determine the OASIS Conceptual Topic Model Area - [Please refer to (link) for appropriate topic area]] Stuckee: Julia (Thu.) EDIT TASK 06: Put in reference to CAP 1.1 for related spec. Discussion: This should be 'related' as in an example of how the <namespacedXMLContent> may be used. EDIT TASK 07: Add more History. Stuckee: Tom (Thu.) EDIT TASK 08: Add or delete Example Usage Scenario Stuckee: Sukamar (Thu.) EDIT TASK 09: Check for consistent bolding and bracketing
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]