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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

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


Subject: RE: [emergency-if] Infrastructure Meeting Today.


Title: Infrastructure Meeting Today.

I think the difference here is that:

·         UCORE is DoD, not international, and has a lot of unnecessary add-ons that don’t work well for emergency information (think DDMS)

·         UCORE doesn’t provide a mechanism to make informational decisions on information contained within it based on hosted terminology that is region specific

·         The DE does do both of these things

·         If other projects want to use UCORE because it works for them…that’s fine by me.  In fact we did integration work with a number of UCORE projects last week without any problems.

 

The issue here is the purpose of the DE.  I put up a number of requirements, a draft SOP, and a number of issues on the list that basically outlines the DE as a header/payload structure that allows for delivery and exposure decisions to be made on it.  We need to agree on a specific purpose for the DE.

WRT to this list; here are my thoughts

1.      Unique message identity – I agree

2.      Distribution infrastructure – This is an implementation concern and we shouldn’t be building a data standard around an implementation; however I agree that some protocols need to be formalized to exchange valuelist information

3.      Delivery Status – Not sure what this means

4.      Policy based adjudication between Social Structures – Again, the data should be there to do this, but with a clear protocol in #2, this is an implementation issue

5.      Capability to hand off to other distribution systems and preserve Policy based routing. – IMO We are not dictating policy in this standard.  We are holding information in the header to make decisions on.  If we want to do policy exchange we need a clear way to express that in the DE data structure and a standard protocol to exchange it.  We have neither at this point.

6.      Subscription for Messages based on target Area. - Agree

7.      Ability to deliver Multiple Content Objects. – Agree

8.      Ability to deliver both XML and Non-XML content. - Agree

9.      Ability to describe Content Objects to determine specific application consumption needs – Agree but separate content keywords and DE keywords creates unnecessary disambiguation, Content Objects in a single DE *should* be related, and in 2.0 could be references by the COid.

10.     Ability to extract key element needed for deliver decision from encrypted content. – IMO this should be covered in the keywords, but if there is a specific use case that illustrates how the keywords won’t work, then I’m all ears

11.     Ability to provide granular Willingness information at multiple levels. (content, content object and entire message) – Again, I disagree on this.  If there are differing sensitivity levels or willingness factors, to me, that represents different distributions, which would in turn dictate multiple DE messages.  Again if there is a clear technical use case to support this I would like to explore it, however I think that this creates a lot of unneeded complexity, and for where we stand now, doesn’t provide a solid implementation strategy without dictating the user implement a specific system.

 

-Don

Office: 315-838-2669

Cell: 703-595-9375

dmcgarry@mitre.org

 

From: David E. Ellis [mailto:dellis@sandia.gov]
Sent: Tuesday, June 22, 2010 10:18 AM
To: McGarry, Donald P.; emergency-if@lists.oasis-open.org
Subject: RE: [emergency-if] Infrastructure Meeting Today.

 

All

 

I agree with Don.  I have an understanding with the technical UCORE architect about the use of the different standards UCORE versus the EDXL-DE.  That said.  The SAIC team which creating UICDS decided to strip the DE header from messages like OASIS EDXL-RM and use UCORE for data subscriptions.  This works if you neglect all the issues considered in developing the original DE 1.0.  If we want to use only use certain distribution topologies, UCORE is a US government standard for expressing this type of information.  The DE however is  a International standard and needs to support other capabilities.

 

Dave

 

From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Tuesday, June 22, 2010 8:00 AM
To: Ellis, David; emergency-if@lists.oasis-open.org
Subject: RE: [emergency-if] Infrastructure Meeting Today.

 

I think before we dig too deep into the details of that we need to address this topic:

the DE is often thought of as Metadata for contents in a data storage repository or for display on COP like UCORE.”

 

There is no consensus on this item and we need to formally define the statement of purpose for the DE before we move into anything else.

 

-Don

Office: 315-838-2669

Cell: 703-595-9375

dmcgarry@mitre.org

 

From: David E. Ellis [mailto:dellis@sandia.gov]
Sent: Tuesday, June 22, 2010 9:57 AM
To: emergency-if@lists.oasis-open.org
Subject: [emergency-if] Infrastructure Meeting Today.

 

All;

I would like to use today’s meeting to prepare for the Face-to-Face next week.  I have attached a word document for consideration about the structure and use of EDXL-DE element with the Routing infrastructure.  This is really important because even after literally years of discussion, the DE is often thought of as Metadata for contents in a data storage repository or for display on COP like UCORE.   I would like to use the attached to explain.

The first thing which became obvious was this needed to have significant flexibility.  There were needs for:

1.      Unique message identity

2.      Distribution infrastructure

3.      Delivery Status

4.      Policy based adjudication between Social Structures

5.      Capability to hand off to other distribution systems and preserve Policy based routing.

6.      Subscription for Messages based on target Area.

7.      Ability to deliver Multiple Content Objects.

8.      Ability to deliver both XML and Non-XML content.

9.      Ability to describe Content Objects to determine specific application consumption needs

10.     Ability to extract key element needed for deliver decision from encrypted content.

11.     Ability to provide granular Willingness information at multiple levels. (content, content object and entire message)

I would also like to discuss the draft Hans has provided Also.  It can give us some topics to consider.

Jeff, I have a Lab inspection which will run right up to the start of the call.  Please take attendance and have the subcommittee discuss your minutes.  Please do not submit material which is not covered by the EM committee IPR rules. <<...>>

David E. Ellis

(505) 844-6697



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