[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=37648#comment-37648 ]
Art Botterell edited comment on EMERGENCY-8 at 6/6/14 2:45 PM:
---------------------------------------------------------------
The TC discussed how best to represent this sort of supplemental information at great length... and with considerable vigor... back in the 1.0 deliberations. There was strong support for allowing inclusion of "rich media" of various sorts, but also strong reluctance to allow unbounded increases in alert message size that might negatively impact (or at least hamper adoption in the case of) transmission technologies of limited bandwidth.
The compromise we reached was that <resource> values should be "dereferenced"... that is, encoded and transmitted as part of the alert itself... only over networks like high-capacity data broadcasts that a) had the bandwidth to handle them, and b) transmits only one-way and thus couldn't offer the client the option of retrieving the extended material separately if and when desired. (Indeed, as I recall the term "dereferenced URI" was suggested by Eliot.)
In all other cases the <derefUri> was (and is) deprecated and inclusion-by-reference preferred: a URL and some content-type info is offered so individual clients can retrieve it if necessary. E.g., there'd be no requirement for an audio interface to retrieve an image, so why impose that load on every receiving device? This arrangement also permits <resource> to point to ongoing streams as well as discrete files.
That implies a "gateway" conversion at the boundaries between one-way and two-way networks, which is addressed in Note 4 of the derefUri definition in the spec. I'm not sure that's ever actually been implemented, but it was thought through at the time.
The <resource> scheme has worked out well when its been used, as in IPAWS, and it seems like the use-cases you offer in your deck could all be handled within the existing framework. The real problem seems to be that many folks don't appreciate how flexible <resource> actually is.
Also... two quick observations on the argument that "XML is extensible." First, that's true, and CAP doesn't need to try to duplicate it; like any document type, CAP has a particular purpose and creeping too far from that risks bloat and user confusion. And second, CAP isn't based on XML, it's based on social science about the content of effective warning messages. CAP is a data structure that can be serialized using XML, ASN.1 and potentially other encodings. XML is neither a cause nor a necessary effect, it's just the serialization that happened to be most in vogue at the time CAP was devised.
was (Author: acb):
The TC discussed how best to represent this sort of supplemental information at great length... and with considerable vigor... back in the 1.0 deliberations. There was strong support for allowing inclusion of "rich media" of various sorts, but also strong reluctance to allow unbounded increases in alert message size that might negatively impact (or at least hamper adoption in the case of) transmission technologies of limited bandwidth.
The compromised we reached was that <resource> values should be "dereferenced"... that is, encoded and transmitted as part of the alert itself... only over networks like high-capacity data broadcasts that a) had the bandwidth to handle them, and b) transmits only one-way and thus couldn't offer the client the option of retrieving the extended material separately if and when desired. (Indeed, as I recall the term "dereferenced URI" was suggested by Eliot.)
In all other cases the <derefUri> was (and is) deprecated and inclusion-by-reference preferred: a URL and some content-type info is offered so individual clients can retrieve it if necessary. E.g., there'd be no requirement for an audio interface to retrieve an image, so why impose that load on every receiving device? This arrangement also permits <resource> to point to ongoing streams as well as discrete files.
That implies a "gateway" conversion at the boundaries between one-way and two-way networks, which is addressed in Note 4 of the derefUri definition in the spec. I'm not sure that's ever actually been implemented, but it was thought through at the time.
The <resource> scheme has worked out well when used, as in IPAWS, and it seems like the use-cases you offer in your deck could all be handled within the existing framework. The real problem seems to be that many folks don't appreciate how flexible <resource> actually is.
Also... two quick observations on the argument that "XML is extensible." First, that's true, and CAP doesn't need to try to duplicate it; like any document type, CAP has a particular purpose and creeping too far from that risks bloat and user confusion. And second, CAP isn't based on XML, it's based on social science about the content of effective warning messages. CAP is a data structure that can be serialized using XML, ASN.1 and potentially other encodings. XML is neither a cause nor a necessary effect, it's just the serialization that happened to be most in vogue at the time CAP was devised.
> 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
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]