Excerpts from Issues for EDXL-DE we need to add to issues listfor 2.0

["David E. Ellis" <dellis@sandia.gov>]

Title: Excerpts from Issues for EDXL-DE we need to add to issues list for 2.0

Don

Here are some issues I have gleaned from the past.  I was not the issues list keeper and there have been many things deferred but may now be lost.  I believe Rex is going to send you a current example of how to maintain an issues list.

Dave

1.      EDXL-DE Update

Tim has agreed with the resolution that EDXL-DE can have multiple contentObjects with one and only one payload each, and one and only one DistributionType, so that no contentObjects could be of a type different than the DistributionType. Patti has incorporated this into the latest version of the draft. This was the only remaining issue on the EDXL-DE draft.

_____________________________________________________________________________________________________________________________________________

a.      Dave said there was a deadline of 8 January to respond to ITU.  Elysa stated that we certainly want to respond to each of the 3 issues that have been discussed; we have no requirement to respond to ITU by that date.  As Jamie instructed us, the OASIS staff has the responsibility to address the ITU.  We will put these topics on the agenda for discussion but discussion could also begin now on the list.  Dave is most concerned about points that effect the DE and will get with Rex on the issues.  Elysa added that all three points will require special discussion and may need separate meetings to address them

_______________________________________________________________________________________________________________________________________________________

Dave Ellis has identified some possible issues with various applications using FIPS 5, FIPS 6 and UNLoCode. Dave is continuing to research the issue and will have a more formal listing for the issues raised.

______________________________________________________________________________________________________________________________________________________

2.      EDXL-DE

a.      Remaining Issues

The remaining issue with the DE is with regard to the <any> element.  There was much discussion on the call about this relative to Dr. Iannellas comments on the list.  A variety of opinions were discussed.  Signatures for target area and differed for a future resolution.  It was agreed that we would add a clarifying comment to the data dictionary as follows.  We realize this is possibly not optimal but can be revisited at the next revision.

b.      Changes since 60 day public review are being summarized by Patti.

c.      Path Forward

Dave Ellis pointed out again how important it was to get the DE through as soon as possible.  They are using it in the Alerting Framework and must move ahead.  We discussed the fact that the changes made to the DE since the 60 day comment period were minor in nature.  Since there are changes, the document must go back out for a 15 day public review.  The reviewers will only be able to comment on the items that have changed.  Patti will make the changes per our call today and post it to the site.  All agreed to review the document and schema to make sure all comments are appropriately addressed.  We will have a meeting January 17 at 12:00 EST.  A vote will be taken to submit this draft for a 15 day review.  This vote will require a full majority vote.  An electronic ballot is not necessary.  Once we have done this, Mary will post the documents on the OASIS site (either 1/17 or 1/18).  The 15 day review will run through Feb 2 or 3.  We will be able to address any comments raised during that period until Feb 6.  We will call a special meeting if necessary to address any comments.  We will have a regularly scheduled meeting on 2/7.  At that time we will vote to 1)  to approve this document as a Committee Specification and 2) to take this Specification to OASIS for a vote to ratify as a Standard.  It will be submitted to the OASIS wide community on the 15^th.  The actual OASIS wide ballot will run from March 16-31.

3.      Consideration of Dr. Iannella’s proposal for the EDXL DE model

The group noted Dr. Iannella’s formal objection to consideration of the current EDXL DE draft as a proposed committee draft. Elysa recognized the amount of thought and effort Dr. Iannella put into his proposed model, and apologized to him in absentia for not acknowledging it earlier.

She then asked the group if they had fully considered the model proposed by Renato.  Several members (specifically Rex, Tom, Gary, David, Michelle and Sylvia) expressed that they reviewed the comments and felt like each had been addressed.  Rex said that Renato’s model had not been ignored, but that he himself had referenced it during the initial discussions and had adopted many of its ideas during the interim phase, and that it had proven very helpful. However, the DOM model seemed to be the consensus of the group. Gary said that he liked the information model very well from a design standpoint, but that as work progressed they had decided that creating a more meaningful organizational model would require a different structure. The current proposal combines ideas from Renato’s model with other members’ ideas, as well as the concepts formulated at the New Orleans meeting. Art expressed concern that a model that was originally provided as a suggestion to the committee is now being framed as an alternative. It was also noted that Dr. Iannella’s model was never adopted by the committee.

The committee then considered whether it would be useful to have an information model in addition to the DOM. Carl brought this up and informed us that both a logic and data model are represented in the OGC specifications.  Rex felt that it might be confusing to add the information model, and would cause a delay in release of the proposal. Patti suggested including the information model in the “cookbook” implementation guide she’s working on.  The group agreed that the current DOM would be the only model in the specification.

4.      Outstanding EDXL DE issues

We discussed how we are going to manage the issues and versions in this fast-paced week of trying to finish up this Committee Draft.  Michelle started an issues list via the list.  These with their status are contained in subsequent paragraphs.  We are asking anyone at this point when an issue is raised to please also offer a proposed solution for discussion and any ramifications they envision.  The document in its current form will be numbered EDXL/DE 0.1.  Each time we make changes, this number will increment until we get to the 1.0 committee draft.

Michelle led the discussion on outstanding EDXL DE issues. She asked for volunteers to maintain a more formal list of issues, and Art volunteered to do so taking the initial feed from Michelle’s’ handoff today. He strongly encouraged anyone submitting an issue to include with it an affirmative suggestion.

David agreed to write up the issue of value list and value pairs being able to appear multiple times, and to provide his suggested implementation.

Michelle is going to write up, for further discussion, the choice among URI, derefURI, and XML namespace.

There was discussion of the appropriate name for the location element. Everyone liked the idea of including UN in a way that wouldn’t be confusing. Art suggested using locCodeUN, and the group agreed.

Sukumar noted that the current draft could use more of a history, which David and Tom are working on. Elysa offered to help with that effort. To offer an example usage scenario, Sukumar will provide the prototype he used for his earlier demonstration to Michelle by Thursday.

Julia will get the identifier number and other designators required by OASIS from Mary.

The following details were submitted by Michelle to the list but are put here as well.  All of the "PROCESS", "ISSUE" and "EDIT TASK" items were noted in the meeting except the third PROCESS note.  That is Michelle’s suggestion as to how to facilitate communication. It might also be good if we also prefaced the subjects of our emails as "EDXL_DE_ISSUE, for example.

5.      EM data exchange initiatives

The group discussed changes in U.S. agencies and warning initiatives that may impact the committee’s work. Dave updated the group on NorthCom, which has been given the lead in meetings to take place in early January, and which he will be assisting. DMIS is now capable of handling EDXL content, but is not able to store data having to do with pre-event detection or tracking of individuals. The Domestic Nuclear Detection Office (DNDO) is doing a joint pilot with the Department of Justice. Tom and Dave are going to be leading the sensor architecture effort. Infrastructure was going to look at existing sensor systems,  and whether they would recommend to the committee that they work on a new sensor schema. DNDO has expressed interest in using the ANSI 4242 standard as content for an EDXL message. Tom is waiting to hear back from Michelle on her sensor standards survey.

Liaison Assignments:  Art agreed to be the coordination point for the ITU-T, Tom and Dave will continue with the sensor work in the IF-SC and represent the TC at the NIST and other sensor standard discussions.  Patti agreed to represent the TC to the HS Standards group she has just joined.  Elysa is to have a telecon with Jamie and Mary of OASIS about liaison relationships.  DNDO specifically asked Elysa to look into how they would become members of OASIS and in what capacity they should/could serve.  They also asked about how MOA and other type of relationships existed between OASIS and other standards bodies, specifically ANSI and OGC. 

A persistent issue has been the ability to test prototype standards. Dave currently doesn’t have anyone test the DE with, but should be able to do so with the MyState site soon. Next would be CIST, in order to test security, including SSL. After that, the committee should consider interface standards to commercial systems.

6.      EDXL-DE Progress

The current plan is to put the draft revision out for comment on January 7^th. The key change is that the ANY element has been put back in. With the addition of the choice statement, signatures will no longer automatically work. The ANY element will be required at the end of a sequence in order to sign a content object.

There was discussion of whether it was possible to put a namespace in an element without first declaring it. If not, that will require another change in order to have an ANY element and an ANY attribute. This should be checked by others with validation tools. If it doesn’t work, that will require a second change to the draft.

Art Botterell has proposed a change in methodology for the future, which is to create the data dictionary first, validate it, and explain what each element is intended to accomplish. After this is complete, the schema could be created. Dave proposed instead doing both at the same time. Since Art’s proposal had to do with methodology rather than results, Renato’s issue is the only one remaining. Patti is going to finalize the draft and get it out on the list so that Renato can comment if he wishes. She will change both the document and the XSD so they will match.

Once the new draft is OK’d, the 15-day review period can begin. That would allow the ballot to go out for review to the general membership by the end of the month, and for general voting to begin on February 1.

Gary has published a prototype of the DE, but not many people have used it. He may try to get data from Dave to post internally. He asked whether the committee should start working on a “cookbook.” Art suggested publishing sample code for the transport layer. There was discussion about implementation issues and whether WSDL should be the focus, as well as whether Java provides the most transportable architecture. Elysa said it has reached to the point where someone needs to put sample code out on a cookbook. Dave questioned whether that would be possible given that many of the examples will require sensitivity to security issues. Elysa emphasized that no secure data should be in the cookbook. Art noted that even “pretend” sensitive data can be complicated, since there isn’t a security version of “lorem ipsum” yet.

The remaining to-do item is to check with Mary McRae to make sure assumptions about the schedule are accurate.

________________________________________________________________________________________________________________________________________________---

Distribution Type issues

•       Mandatory “enumerations” which are not complete and are causing adoption and semantic ambiguity issues especially in compound messages or workflows.

•       Must determine use within EDXL distribution system

–       Why have this tag anyway? (framework versus edge system)

•       Composition of “distributionType” (URI and/or XRI)

–       Registered EDXL Distribution Systems

–       Distribution System COI label

–       Content Objects Schema / Context

–       Schema/Context Distribution Type

•       Provide guidance for “distributionType” creation and mapping between EDXL Distribution Systems (must be unique)

________________________________________________________________________________________-

Security Labeling Issues:

Controlled Unclassified Information and specific metadata from Federal agencies needs to be discussed for ContentObjectZero

____________________________________________________________________________________________

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:alertRecipien<valueListUrn>

                <value>hazmat.northLine@goRail.com</value>

                <value>application/CAMEO/plumeReport.bat</value>

                <value>fireDepartment@centerCity.gov</value>

</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

7.      EDXL timetable

To fulfill its goal of having a committee draft ready for vote by the end of the week, the group agreed to meet on both Wednesday 3:30 EDT and Thursday 9:00 EDT to continue the discussion.

Respectfully submitted,

Julia Ridgely, Secretary

OASIS EM-TC

President

Long Branch Systems

(443) 604-8699

1.      Outstanding EDXL DE issues

Discussion resumed of the remaining EDXL-DE open issues as posted by Art on the site in the 8/18/05 issues list. 

Michelle thanked everyone who sent comments and contributions to the draft, and said there were three remaining issues to be considered.

       

The first was issue 9, the proposal not to encode payloads that can be delivered by other means. This issue concerns the size of the DE in some implementations where there is limited processing capability and bandwidth at the point where the DE must be processed.  The size issue mainly concerns the <nonXMLContent> and the <derefUri>.  Discussion on the topic continued for some time.  Unfortunately, Kon who raised the issue could not be on the call.  We discussed the size of the DE and the fact that the way it is currently specified, the DE could be very large and could actually have an undetermined size since it could contain live video in the <nonXMLContent>, as a worst case example.  Where most senders will be able to calculate the size and store it in the DE, in some cases, the sender will not be able to determine this size.  David very much needs the ability to have a DE that can have a large <derefURI>.  We discussed how to accommodate both high- and low-bandwidth users. Rex offered a motion to document this as an open issue in the draft but withdrew it after further discussion.  Art moved and David seconded a motion to note this as an implementation issue that is out of scope for the specification.  All agreed. 

As an aside, David said he had not been able to get clearance for the example he offered, so it will be omitted not only from the draft but from the implementation guide and wiki for now.

In consideration of the issue of low-bandwidth users, Gary made a motion that was seconded by Rex to make the <size> be mandatory whenever <derefURI> is used. This will allow systems the ability to know the size prior to ingesting the entire message.  It was discussed that this will only help where the parser does not require the entire message to be ingested at once.  There was also discussion about whether it would make sense to have <size> be mandatory for URI as well but decided against.  We also discussed whether <size> should be able to be indeterminate, e.g., streaming video.  We decided not to do so at this point since streaming data is a different situation and should be considered separately when raised.  The motion passed unanimously. 

The second issue, issue 10 on the list was raised by Renato to rename <derefURI> to <contentData>. We agreed this is a more fitting name, however the EDXL-DE will be inconsistent with CAP 1.1 on this point.  We agreed that when we align these standards at CAP 2.0, we can make the change in CAP from <derefURI> to <contentData> at that time.  A motion was made by Michelle and seconded by Art to make this change in the DE.  The motion passed unanimously.  Michelle will take care to make sure all appropriate references in the document are changed. 

Issue 11, a proposal by Renato to change <valueListURN> to <valueScheme>, was discussed. The impression of the group was that this issue was cleaned up with the resolution of Issue 8 to disambiguate <explicitAddress>.  We discussed the proposal and looked at re-opening issue 8.  We agreed that was not necessary.  A motion was made by Art and seconded by Michelle to respectfully decline the suggestion to rename <valueListURN>.  All were in favor.

All issues had been addressed and we began to do a final review of the remainder of the specification.  Each section of the draft was reviewed by the group with Michelle leading the discussion.  Several editorial corrections were made. 

Art reviewed comments he has received from the public on the Distribution Element. They include making digital signatures mandatory, a tag for language used, and a question about whether there should be multiple XML or non-XML elements. The National Wildfire Coordinating Group requested an incident identifier and description. Art will be preparing and circulating a list of all comments and issues.

__________________________________________________________________________________________________________________________________________________

Open Issues

1.      General Requirement “Incident and Event Reference”.

 In the EDXL Distribution Element, this is handled using a “keyword” element providing the capability to link to any value from a discrete managed list.  This could be used to specify an incident or an event using the Uniform Resource Name (URN) of a published list of values and definitions.  This approach was pursued in an attempt to make the standard more flexible.

ISSUE:  This approach makes the assumption that each resource message – even a resource message containing multiple payloads - will be referencing the same incident or event.  This assumption must be tested and validated.

This issue will be addressed during the OASIS technical committee review process, with input and feedback provided by the Standard Working Group through EDXL project team OASIS members.

____________________________________________________________________________________________________________________________________________________

These are issues from the Face to Face:

Review issues identified during Sept F2F to be addressed in DE follow-on.

Dave Ellis to provide brief context for the current unmet needs in the DE:

1. Acknowledgement (reply to/error to) (Optional, could be 1.1)

Does the message reach the end user?

Define where the grid starts/ends – given distribution technology

Requirement:  The DE shall provide the sender with feedback to confirm transmission of message to the redistribution system(s).

Note:  The DE should support load balancing in methods of redistribution, but it is understood that this is not a requirement of the DE

What is in the 1.1 draft should be reviewed (string or valuelistURN or value scheme) 

Responsible – Included in draft now as string, need to change to structure of explicit address.  Hans

2. Hop count – sounds like a system requirement, not a DE requirement (router specific – Hans/Jeff/Don)

3. Distribution type – mixed mode, content objects with different distribution types.  Note – dependency on current approved standards RM/HAVE.

Needs to be “fixed” in next revision.  Fix or do differently…

Maybe recommend one distribution type per message, need to determine whether the structure needs to be single distribution type or single content with multiple distribution types. (2.0)  Suggest valuelistURN so that other standards (RM/HAVE doesn’t have to change).  Possibly need to add t.  Topic for discussion during IF-SC meeting.  Discussion about adding tags for the routing params (update/cancel..)  Those having specific interest/knowledge (Gary/Tim/Rex/Michelle - need diversity and history)

FORWARD SHALL BE A TYPE – with example and explanation (base64 encode full message, security ramifications, tracking/logging)

4. Re-evaluate header vs content (2.0)

What must be fixed is putting info about the content in the header.  What is used for policy decisions and where it goes – distribution vs contentObject.

If it has to do with routing whole message – Distribution.  If it has to do with routing a piece of content based on specific purposes, it would be in the contentObject.  This will be worked in IF-SC meetings – those having particular interest/knowledge – Michelle/Rex/Gary/ -

5. Conformance section – Dave – five levels of routing, policy/distribution should include conformance for the routing points.

There is a need for different levels of conformance…

DE conformance section must be added, it will have to grown. 

Gary – be careful of over specifying it.

NIMS-STEP folks have offered to provide input

6. Policy methods for routing  - emergency message routing

What are the unique needs of the routing element for emergency needs. 

Where does routing detail go?   Determined that there must be a Routing Specification  (Jeff/Hans/Don/Michelle – others as needed)

1.      Capture detail experience about routing (Jeff/Hans/Don working with Dave)

2.      Create bullet points of what a basic routing capability should be for within the DE spec.  A full blown spec will likely follow…. (Rob)

3.      Routing spec for EM will follow and have its own conformance spec.  (levels vs capabilities – 5 discussed in the early days, Gary added that this should be capabilities)

7. Name space for DE – Name space restriction on content object

NO DE wrapped in a DE – don’t layer Des, specifically for security reasons

Consensus – we will not do this.  (see forward reference in distribution type)

8. URI instead of URN

URN – allows global unique id, doesn’t require going to the web for reference (URNs are controlled – Rex)

URNs are not affective for small county jurisdictions (Don)

High speed routing – URN and locally specified lists can use URI (Gary).  DM-OPEN is taking code lists from NIEM code lists – that can be locally available

URL in current spec mistake,

Don- should be able to use URLs

Question – should the valuelist URN/URI/URL/Code list all be allowed.

Dave will try to provide detail need for URN exclusive – for high level systems

Specific changes to spec – changes from spring to any URI and change the name to valuelistURI (Jeff/Don/Rex/Hans -

9. Non-XML Content – add new element for digest type and update digest to remove SHA-1 (refCOID and COID) – both XML and non-XML content.  Structure (not a string).  Examples need to be included in spec for clarification.  Doug - examples/Hans – update 1.1 tech (CSV), use case (multiple content object)

10.     Area – readdress with next revision, See EM Routing concepts Version 4, Michelle – support multi area geometries, include GML Where, Hans – order of preference for areas.  Michelle – add tagging of level of detail, Doug – need FIPS (SGC).  Request GIS-SC to weigh in and provide guidance Particular interest Carl/Rex/Michelle/Doug/Hans/Rob

11.     Confidentiality and Combined confidentiality – Enumerated list? URN?  This topic must be covered in the next revision.    Keep required but make it a choice – between a string and valuelistURN.  Can’t be ignored.  Rob

12.     xmlContent – OOPS – need to change the name because it is not a valid XML tag name.  Needs to be fixed.  “ContentXML”  - Hans

<<...>>

EDXL_DE_Issues_8-17-05rev1.xls