OASIS Emergency Management TC

RE: [emergency] RE: Question on EDXL-DE schema

  • 1.  RE: [emergency] RE: Question on EDXL-DE schema

    Posted 01-20-2006 01:36
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: RE: [emergency] RE: Question on EDXL-DE schema


    Title: Re: [emergency] RE: Question on EDXL-DE schema
    Art, Renato
     
    At this point the SSIWG can define prototype location schema for sensor content objects and evaluate them be assigning these elements a "testing" namespace.  This will allow continued exploration of needed functionallity.
     
    Once experiments have validated best elements structure (e.g.DoD and DNDO experiments), the SSIWG could recommend either addition of needed elements via EDXL-SS using the namespace=##other elements in current EDXL-DE or propose additions of content object elements for future versions of EDXL-DE.     
     
    David E. Ellis
    Information Management Architect
    (505) 844-6697


    From: Art Botterell [mailto:acb@incident.com]
    Sent: Thu 1/19/2006 5:30 PM
    To: Renato Iannella
    Cc: Emergency_Mgt_TC TC; Mark Carlson - Conneva, Inc.
    Subject: Re: [emergency] RE: Question on EDXL-DE schema

    I had occasion to revisit the notes on digital signatures and 
    encryption in the CAP 1.1 spec... sections 3.3.2.1 and 3.3.2.2 
    respectively.  This was the language contributed by Bob Wyman, and 
    now that I'm getting around to addressing some of those issues, it 
    seems workable, concise and unambiguous.  Maybe it would give us some 
    guidance on how to express what we're trying to do here.

    Meanwhile, I understand that several folks are playing with 
    experimental extensions that they may or may not propose for 
    ratification later.  Might it make sense to create two versions of 
    the schema... a strict one to go in the spec, and an "experimentors' 
    edition" (with the "##anys") in an application note or whatever?  
    That way maybe we could encourage experimentation without diluting 
    the spec itself.

    - Art


    On Jan 19, 2006, at 3:41 PM, Renato Iannella wrote:
    > On 20 Jan 2006, at 04:08, Ellis, David wrote:
    >
    >> The ##other is an acceptable replacement for the ##any value 
    >> located in the any element following the xsd:choice element.  The 
    >> intent of this element in the EDXL-DE schema is to provide a 
    >> mechanism for signing our contentObjects.  The signing process 
    >> (refer to http://www.w3.org/TR/xmldsig-core/) uses a different 
    >> namespace than EDXL-DE.
    > My point has always been that if this is the *intent* of the 
    > element, then that is what we need to clearly
    > indicate in the spec. It is used for digital signatures - full 
    > stop. If we start to say that the *same* element can be use for 
    > 'experimental extensions' then we will have problems in the future 
    > (guaranteed !)
    >
    > The best option to make this explicit is to reference the W3C XML 
    > Digital Signature namespace.
    > All that is needed is to include the DigSig namespace at the top of 
    > the EDXL Schema:
    >
    >   xmlns:ds="http://www.w3.org/2000/09/xmldsig#
    >
    > and in the ContentObjectType, put a reference to the DigSig 
    > Signature element:
    >
    >   <xsd:element ref="ds:Signature" minOccurs="0"/>
    >
    > 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


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