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