[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-if] 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. From: David E. Ellis [mailto:dellis@sandia.gov] 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] 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. From: David E. Ellis [mailto:dellis@sandia.gov] 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]