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: [OASIS Issue Tracker] (EMERGENCY-13) Allow or deny use of alternate (non-text) info formats

Tony Mancuso created EMERGENCY-13:

             Summary: Allow or deny use of alternate (non-text) info formats
                 Key: EMERGENCY-13
                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-13
             Project: OASIS Emergency Management TC
          Issue Type: Improvement
          Components: CAP 
            Reporter: Tony Mancuso

Jacob Westfall; Info blocks: CAP info segments contain information in a text format and many multi-media systems must convert this information to their own media format for use (text-to-speech for radio, etc).  This approach has many benefits since it ensures a common format is used by all systems.  However, the opportunity exists for an issuer to include an alternate version of the info segment information already converted to a media format suitable for public use, such as an audio/video version, through the use of a resource segment. There are two parts to my comment.  The first is asking whether this practice should be allowed.  Is it acceptable to send an alternate version of the info segment's data in another media format, such that a receiving system can use this alternate version as a complete replacement.  Is it better to ensure uniformity by making the text version the only acceptable format, or should replacement formats be allowed?  The next version of CAP should either allow or deny this practice for clarity. The second part of my comment is suggesting the following guidelines and changes to CAP if alternate versions are allowed.  

Guidelines should be included in the CAP document which detail what information must be present in the alternate media format.  So perhaps the video format must include information about the issuing authority, the event, its urgency/certainty/severity, area description, and instructions.  Outlining what the minimum information requirement should be just, like the text schema, and including some sample scripts to use.  Perhaps for video it may be acceptable to have some parts as visual elements and others as audio, etc.  But the key point made in the guidelines is that the information should not differ from the default text version. Changes also need to be made to CAP to accommodate these alternate formats.  Right now you can put this alternate format in a resource segment, but a receiver has no idea whether this is a complete replacement, or just supplemental information.  That is why I don't believe the resource segment should be used for these replacement formats.  Resources are a way to provide supplemental information and I have further comments to send on how to better take advantage of this particular capability.  Instead I suggest a new block be added expressly for the purpose of supporting alternate formats to ensure there is no confusion. When a receiver gets a message with this alternate format included, they can be assured that this media format already contains all of the information present in that info block and instead of creating their own format for distribution they can just substitute this included version.  At this point I'm not suggesting what XML elements to use or tag names, etc, but here is a possible example:

    <mimeType> audio/wav </mimeType>
    <size> 1231231 </size>
    <uri> http://info.wav </uri>
    <derefUri> lkj1k2131kjlj </derefUri>
    <digest> LKskj123 </digest>

This message was sent by Atlassian JIRA

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