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: Re: [emergency] Forwarded note from David Ellis


> > On Wattack.  Our CBRNE Sensor program needs to use the <derefUri>
> > tag to pass sensor and video data.

derefUri is not intended to be used as an ad-hoc video transport. My
question for this issue is - was the time taken by the reader to fully
understand how derefUri is (should be) used, or is the language in the
1.1 spec not clear enough? Or maybe I'm reading this incorrectly and the
intended use is to pass video data metadata parameters.
 
> > NOTE on Null String Comment: The data dictionary for code element in
> > both the CAP 1.0 and 1.1 states Any user-defined flag or special
> > code used to flag the alert message for special handling.  This
> > causes many programmers to think of this as a status integer or some
> > numeric priority code for the message.  Because this is a string and
> > null is allowed if other CAP implementers sends the code tag with
> > blank content the programs using non-string content often fail.  If
> > there is a best practices policy, CAP programs should not send
> > optional tags with null content and should perform checks for now
> > string uses of tags.  I am open to helping work some implementation
> > and/or testing guidance.

I know this was discussed at great length, but I have to add my 2c:

The very fact that CAP is targeted for interoperability means that you
cannot and should not assume that certain pre-defined values will always
be present in free-form fields.

My suggestion would be that the programmer writing the CAP ingest
function actually implement robust validation and handle null
exceptions. Fix the bug, not the spec.

Testing for nulls and non-valid fields is really an XML and schema
issue, not a CAP issue. One should follow best practice guidelines for
dealing with XML and schema data when parsing CAP, not the other way
around.

Error checking is needed irregardless of the validity of the field.
Since the CAP file is plaintext, it is possible that one of the
characters in the field could be corrupted, thus equating to a
non-integer value.

Cheers
Kon




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