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-8) Add hierarchical data to CAP through XML extensions in schema

    [ https://tools.oasis-open.org/issues/browse/EMERGENCY-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37644#comment-37644 ] 

Steve Hakusa commented on EMERGENCY-8:

My apologies, that version has no speaker notes, so it's more difficult to see resources addressed on slide 28.
The one uploaded to OASIS has speaker notes:
and here's the same file as a public Google doc: https://drive.google.com/file/d/0B6KjI0JA9k3hM2cwd2EtcEd6N1k/edit?usp=sharing

Here are the notes from slide 28:
- At the [2013] WMO CAP Workshop, Eliot Christian mentioned an even shorter-term alternative for supporting XML extensions; base-64 encode them and add them to a <reference> via the <derefUri>.
- Base-64 encoding is the obvious undesirable property of this solution.  It does not seem like something that we would want to recommend to other countries as the "way to implement CAP with your data".
- It is reasonable, if it was more palatable, to change CAP to allow non-encoded XML in a <resource>, instead of allowing XML extensions at the <info> level.  We would prefer just allowing extensions at the <info> level, because it makes the CAP somewhat easier to read and work with.

The speaker notes do not answer an obvious follow-up, "Why not just put the extension data in a separate file and refer to it by URI using <resource><uri>?"

One answer is practical: it's slower, more error-prone, and just more complicated to fetch additional content by URL.  I'd argue that the most would choose instead to stuff data into one or more parameters (eg slide 13), which I don't think anyone agrees is good practice.

I'd also argue that when the content is so relevant to encouraging users to take action on an alert, (eg "for a set of affected cities, how high is the tsunami going to be, what time will it arrive", or "the set of personal details to help someone recognize the missing child"), it feels uncomfortable to stick the information in a "resource".  You may counter by saying, "if the content is so important, it should be in the description", and you're right: a plain-text summary should indeed be in the description field.  But plain text just isn't the most useful or actionable way to present all information, and it seems wrong for the standard to hamstring systems (and I'm not just talking about Google here) that are can present the information in a way that's easier to understand.

> Add hierarchical data to CAP through XML extensions in schema
> -------------------------------------------------------------
>                 Key: EMERGENCY-8
>                 URL: https://tools.oasis-open.org/issues/browse/EMERGENCY-8
>             Project: OASIS Emergency Management TC
>          Issue Type: Improvement
>          Components: CAP 
>            Reporter: Tony Mancuso
>              Labels: CAP
> Steve Hakusa: To add hierarchical data to CAP, allow XML extensions in the CAP schema through the following change to the .xsd: <any minOccurs="0" maxOccurs="unbounded" namespace="##other"    processContents="lax" />
>   a. Allow such XML extensions at the <info> level, and optionally at the <alert> level. Having extensions at the <info> level would be required in case the hierarchical data is language-specific.  Extensions at the <alert> level could cut down on redundancy in the case the data is related to all <info> blocks.
> Jacob Westfall: Add extensibility with <xs:any## other minOccurs="0"/> 

This message was sent by Atlassian JIRA

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