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: Video in <derefUri>

Of course, strictly speaking, I don't think anything flatly forbids 
the inclusion of encoded video in <derefUri>.  The special 
restrictions on that element address concerns about the risk of 
enormous CAP objects impacting unprepared transport networks 
(including the public Internet.)  As long as the appropriate bounds 
are respected as to where any such relatively-jumbo messages might 
travel... and in the CBRN sensor context it seems pretty clear that 
there would be... the <derefUri> element doesn't really care about 
the type of the content.

That said, the use of <derefUri> to encapsulate meta-data seems 
especially prudent, where feasible, since those inclusions are 
relatively small.

- Art

At 6:06 PM -0800 1/12/05, Kon Wilms wrote:
>  > > 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
>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.
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

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