OASIS Emergency Management TC

Re: [emergency] CAP 1.1 Issue # 11

  • 1.  Re: [emergency] CAP 1.1 Issue # 11

    Posted 07-28-2005 00:23
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: Re: [emergency] CAP 1.1 Issue # 11


    Yes, I think we got a pretty good consensus on yesterday's call that  
    changing to a URN namespace name and keeping the namespace mandatory  
    in <alert> met Patti's concerns while also avoiding the single-point- 
    of-failure problem created by an implied schema location.  The latest  
    CAP 1.1 draft reflects that approach.
    
    - Art
    
    On Jul 27, 2005, at 7/27/05 4:12 PM, Renato Iannella wrote:
    
    >
    >
    > On 28 Jul 2005, at 01:10, Carl Reed OGC wrote:
    >
    >
    >> I support the idea of a version number 100%. Clients and servers  
    >> need to be able to do version negotiation. Without this, then  
    >> interoperability suffers (like perhaps none at all). All OGC specs  
    >> have version numbers as part of the interface specification and  
    >> this information is expressed in each interface call or payload  
    >> encoding. An interesting side benefit is that applications can  
    >> then actually support multiple CAP versions.
    >>
    >
    > Carl/Patti - the CAP XML Namespace (which is mandatory) will always  
    > tell you what
    > version of CAP you are parsing. Isn't this the same thing? (or am I  
    > missing something?)
    >
    >
    > Cheers...  Renato Iannella
    > National ICT Australia (NICTA)
    >
    >
    > ---------------------------------------------------------------------- 
    > ----
    > This email and any attachments may be confidential. They may  
    > contain legally
    > privileged information or copyright material. You should not read,  
    > copy,
    > use or disclose them without authorisation. If you are not an intended
    > recipient, please contact us at once by return email and then  
    > delete both
    > messages. We do not accept liability in connection with computer  
    > virus,
    > data corruption, delay, interruption, unauthorised access or  
    > unauthorised
    > amendment. This notice should not be removed.
    >
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  You may a link to this group and all your TCs  
    > in OASIS
    > at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    >
    
    


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