EM Messages and Notification SC

 View Only

RE: [emergency-msg] ICS form req's draft

  • 1.  RE: [emergency-msg] ICS form req's draft

    Posted 07-18-2003 16:45
    At 8:33 AM -0400 7/18/03, Allen Wyke wrote:
    >Maybe I am not understanding "how" you are planning on using the 
    >subset. Are you proposing to use the same structure as used in CAP, 
    >OR are you saying to use CAP ("connection" implies use CAP)?
    
    How can I  say this any more plainly? Nobody has suggested importing 
    any structure from any other schema.  (In fact, structure hasn't been 
    discussed at all... that's a later step in the SC's agreed-upon 
    process.)  All that has been suggested is that certain elements that 
    were used elsewhere might also be useful in the new (ICS-201) schema. 
    To enumerate, we're talking about some or all of:
    
    Message ID (identifier)
    Sender ID (sender)
    Sent Date/Time (sent)
    Status (status)
    Scope (scope)
    Type (msgType)
    Password (password)
    Operator/Device ID (source)
    Restriction (restriction)
    Address (address)
    Handling Code (code)
    Note (note)
    Reference ID (reference)
    Incident ID (incident)
    
    If (and only if) we decide that some or all of those elements would 
    be useful in the ICS format, then the next question will be how best 
    to implement that.  We could create a joint data dictionary, as has 
    been suggested on several occasions.  Or we could create a 
    spaghetti-plate of inter-schema references, although that wouldn't be 
    my recommendation.  Or we could simply include identical element 
    names and definitions in the new spec, which would be inelegant, 
    perhaps, but quick and simple for purposes of discussion, and easily 
    transformed into a more elegant formulation later.
    
    But those are two separate questions; until we decide there's 
    actually a need for some or all of those elements, it seems premature 
    to argue about the mechanics of including them.  What's on the table 
    right now is a requirements document, which by definition focuses on 
    "what" rather than "how."
    
    Of course, if someone in the TC or the IF SC wants to bring forward a 
    constructive process proposal on how the TC should do this sort of 
    thing globally, that would be wonderful.  But this SC has been asked 
    to move ahead, and in the absence of a TC policy we've tried to do so 
    in the simplest, quickest and most transparent way we can devise.
    
    I appreciate everyone's cooperation and assistance in getting so much 
    productive work done so quickly so far, and I very much hope we'll be 
    able to proceed in the same spirit.
    
    - Art