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

OK, I think see the problem ... the data 
dictionary doesn't explicitly describe it as a 
string (although it is defined as such in the 

Generally speaking I think it's poor programming 
to assume a constraint that isn't in the spec... 
in this case, to assume that a null value will 
never appear in this field.  However, if it will 
make life easier for folks either to warn 
explicitly that null values may occur, or to 
explicitly ban them in the dictionary and the 
schema, I certainly wouldn't object.

Of those two options, my personal preference (a 
mild one) would be for an advisory note rather 
than a technical restriction... mainly on the 
theory that it keeps our options open and also 
that it's more robust in the long run than trying 
to protect against every possible bit of brittle 
coding.  (It also covers the standard 
empty-element equivalent form of "<code/>"... the 
very existence of which seems to suggest that 
empty elements are a fact of XML life.)

I don't imagine adding the required null-checks 
would be an onerous burden for implementers once 
the point is clarified.

- Art

>>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.

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