OASIS Emergency Management TC

 View Only

Re: [emergency] Forwarded note from David Ellis

  • 1.  Re: [emergency] Forwarded note from David Ellis

    Posted 01-13-2005 02:41
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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 
    schema.)
    
    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]