OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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.

Best regards,

Michelle


NOTE: I've embedded comments in the previous notes and added the
Status after previous notes. Previous notes are preceded by the '>'
symbol.



ISSUE ID: 1  - RESOLVED (CLOSED)

> ISSUE: Use of multiple <value> elements in conjunction with a <valueListUrn> element, where the values are from the value list, should be supported.

NOTE: There was a typo in the previous notes.  The <valueListUrn>
element should be closed before any <value> elements are included.
Thus, the example should be:
Example:
<consumerRole>
	<valueListUrn>railway:sensor:hazamat:alertRecipient</valueListUrn>
		<value>hazmat.northLine@goRail.com</value>
		<value>application/CAMEO/plumeReport.bat</value>
		<value>fireDepartment@centerCity.gov</value>
 </consumerRole>

Status: COMPLETE, Changes were made in the schema, spec and
documentation version 0.1.  All three documents are available in KAVI.



ISSUE ID: 2 -  RE-DIRECTED (CLOSED)

NOTE: Dave wrote up this issue as noted below this previous section
and discussion was conducted. For full details see email thread "EDXL
DE "issue" location metadata for <contentObject>."

> ISSUE: Add a <location> element to the <contentElement>.
> 
> Originator: Dave Ellis
> 
> Action: Dave to write up rational and proposal.

ISSUE: There needs to be a way to provide <contentObject> origination
location metadata for sources of <namespacedXMLContent>.

Originator: Dave Ellis

Rationale:  Many fixed sensors do not report their location while
reporting a potential detection.  This can be for many reasons form
design limitations to security of wireless transmission of detection.


Suggestion: Use labels as in the following schema (similar to CAP 1.1
and/or CAP 1.0) but names of elements could be changed for clarity.

NOTE: This means adding <XMLContentLocation> as a sub-element of
<contentObject> when appropriate.

<element name = "XMLContentLocation" minOccurs = "0" maxOccurs = "1">
   <complexType>
       <sequence>
           <element name = "locationLabel" type = "string"/>
           <element name = "location" type= "string"/>
       </sequence>
   </complexType>
</element>

Proposal:  Don't add to <contentObject> within this pass of the
EDXL_DE_Spec_Draft and leave for public comment.
Proposal:  Take up the issue of sensor and event location within  the
Sensor discussion, outside the current scope of the
EDXL_DE_Spec_Draft.

NOTE: Suggestion made that an example using the location data pulled
from the <namespacedXMLContent> be placed in the <keyXMLContent>
element in the cookbook or in the radiation sample.  (This does not
deal with the not XML content possibility.)

NOTE: Further discussion determined that  nested levels of content and
distribution should be looked at. This is to be done outside the work
for the current EDXL_DE_Spec_Draft.

Action: Removed from consideration for the current EDXL_DE_Spec_Draft.
 Referred to Sensor and other discussions.



ISSUE ID: 3 - DELAYED (Action to be taken today)
	
> 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 ID: 4 - RESOLVED (CLOSED)

> ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea> element is too generic.
>
> Proposal: Rename <location> to <locCodeUN>.

Status: COMPLETE, Changes were made in the schema, spec and
documentation version 0.1.  All three documents are available in KAVI.

NOTE: A typo exists in the Issues table.  The new name should be
<locCodeUN> not <loCodeUN>.



ISSUE ID: 5 - RESOLVED (CLOSED)

> ISSUE: <originatorRole> and <consumerRole> provide less confusion
> against <senderRole> and <recipientRole> but do not disambiguate
> clearly. 
> 
> Originator: Michelle Raymond
>
> Action: Leave as is.



NEW ISSUE: We need to consider expanding the restriction of <senderID>
to more than an individual "e-mail address".

Originator: Dave Ellis

Rationale: The CAP philosophy of messages being sent from "people" to
"people" thru application interface forms is not the "machine" to
"machine" EDXL philosophy.  Sensor devices are not always uniquely
associated with a domain and they are for sure not sent by an
individual actor.  In fact, most are on private "e.g. 10.1.1.1"
internet non-routable networks.  Because there are so many
instantiations of these types of sensor networks we have explored MAC
addresses of devices NICs for identifying the unique source of the
application device sending the EXDL message.

Suggestion: Use a MAC ID in the <senderID>.

Proposal: Leave the definition as "Unique identifier of the sender."
Modify the comments to reflect this is not a formal "email address".

Discussion: How to 'get back' to the sender? or at least associate the
sender with a specific domain?

Proposal: Leave definition and comments, but add examples of 'actors'
where one is a common prefix for an email address and another is a MAC
ID.

Action: Add examples to the specification comments and schema documentation.


 
NOTE FOR TASK 00: - ****HIGHLIGHTED, BOLD, BLINKING****, do it now, or
suffer later at the hands of the public.

> 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.)
Status: Sukamar working on it.
Action: Sukamar will send to Michelle for incorporation.


> 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.)
Status: Tom sent draft to David for review.  
Action: David will send to Michelle for incorporation.


> EDIT TASK 08: Add or delete Example Usage Scenario 
> Stuckee: Sukamar (Thu.) 


> EDIT TASK 09: Check for consistent bolding and bracketing


NEW EDIT TASK 10: Add back in the Revision history as Appendix D. 
Stuckee: Michelle
NOTE: I've embedded comments in the previous notes and added the Status after previous notes. Previous notes are preceded by the '>' symbol.



ISSUE ID: 1  - RESOLVED (CLOSED)

> ISSUE: Use of multiple <value> elements in conjunction with a <valueListUrn> element, where the values are from the value list, should be supported.

NOTE: There was a typo in the previous notes.  The <valueListUrn> element should be closed before any <value> elements are included.
Thus, the example should be:
Example:
<consumerRole>
	<valueListUrn>railway:sensor:hazamat:alertRecipient</valueListUrn>
		<value>hazmat.northLine@goRail.com</value>
		<value>application/CAMEO/plumeReport.bat</value>
		<value>fireDepartment@centerCity.gov</value>
 </consumerRole>

Status: COMPLETE, Changes were made in the schema, spec and documentation version 0.1.  All three documents are available in KAVI.



ISSUE ID: 2 -  RE-DIRECTED (CLOSED)

NOTE: Dave wrote up this issue as noted below this previous section and discussion was conducted. For full details see email thread "EDXL DE "issue" location metadata for <contentObject>." 

> ISSUE: Add a <location> element to the <contentElement>.
> 
> Originator: Dave Ellis
> 
> Action: Dave to write up rational and proposal.

ISSUE: There needs to be a way to provide <contentObject> origination location metadata for sources of <namespacedXMLContent>.

Originator: Dave Ellis

Rationale:  Many fixed sensors do not report their location while reporting a potential detection.  This can be for many reasons form design limitations to security of wireless transmission of detection.	


Suggestion: Use labels as in the following schema (similar to CAP 1.1 and/or CAP 1.0) but names of elements could be changed for clarity.

NOTE: This means adding <XMLContentLocation> as a sub-element of <contentObject> when appropriate.

<element name = "XMLContentLocation" minOccurs = "0" maxOccurs = "1">
   <complexType>
       <sequence>
           <element name = "locationLabel" type = "string"/>
           <element name = "location" type= "string"/>
       </sequence>
   </complexType>
</element>

Proposal:  Don't add to <contentObject> within this pass of the EDXL_DE_Spec_Draft and leave for public comment.
Proposal:  Take up the issue of sensor and event location within  the Sensor discussion, outside the current scope of the EDXL_DE_Spec_Draft.

NOTE: Suggestion made that an example using the location data pulled from the <namespacedXMLContent> be placed in the <keyXMLContent> element in the cookbook or in the radiation sample.  (This does not deal with the not XML content possibility.)

NOTE: Further discussion determined that  nested levels of content and distribution should be looked at. This is to be done outside the work for the current EDXL_DE_Spec_Draft.

Action: Removed from consideration for the current EDXL_DE_Spec_Draft.  Referred to Sensor and other discussions.



ISSUE ID: 3 - DELAYED (Action to be taken today)
	
> 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 ID: 4 - RESOLVED (CLOSED)

> ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea> element is too generic.
>
> Proposal: Rename <location> to <locCodeUN>.

Status: COMPLETE, Changes were made in the schema, spec and documentation version 0.1.  All three documents are available in KAVI. 

NOTE: A typo exists in the Issues table.  The new name should be <locCodeUN> not <loCodeUN>.



ISSUE ID: 5 - RESOLVED (CLOSED)

> ISSUE: <originatorRole> and <consumerRole> provide less confusion
> against <senderRole> and <recipientRole> but do not disambiguate
> clearly. 
> 
> Originator: Michelle Raymond
>
> Action: Leave as is.



NEW ISSUE: We need to consider expanding the restriction of <senderID> to more than an individual "e-mail address".

Originator: Dave Ellis

Rationale: The CAP philosophy of messages being sent from "people" to "people" thru application interface forms is not the "machine" to "machine" EDXL philosophy.  Sensor devices are not always uniquely associated with a domain and they are for sure not sent by an individual actor.  In fact, most are on private "e.g. 10.1.1.1" internet non-routable networks.  Because there are so many instantiations of these types of sensor networks we have explored MAC addresses of devices NICs for identifying the unique source of the application device sending the EXDL message.  

Suggestion: Use a MAC ID in the <senderID>.

Proposal: Leave the definition as "Unique identifier of the sender." Modify the comments to reflect this is not a formal "email address". 

Discussion: How to 'get back' to the sender? or at least associate the sender with a specific domain?

Proposal: Leave definition and comments, but add examples of 'actors' where one is a common prefix for an email address and another is a MAC ID.

Action: Add examples to the specification comments and schema documentation.


 
NOTE FOR TASK 00: - ****HIGHLIGHTED, BOLD, BLINKING****, do it now, or suffer later at the hands of the public.

> 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.)
Status: Sukamar working on it.
Action: Sukamar will send to Michelle for incorporation.


> 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.)
Status: Tom sent draft to David for review.  
Action: David will send to Michelle for incorporation.


> EDIT TASK 08: Add or delete Example Usage Scenario 
> Stuckee: Sukamar (Thu.) 


> EDIT TASK 09: Check for consistent bolding and bracketing


NEW EDIT TASK 10: Add back in the Revision history as Appendix D. 
Stuckee: Michelle











[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]