OASIS Emergency Management TC

 View Only

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

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

    Posted 01-22-2006 14:51
     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


    Thanks Elysa,
    
    I appreciate the clarification.
    
    Regards,
    Rex
    
    At 6:29 AM -0600 1/22/06, Elysa Jones wrote:
    >Rex and others,
    >
    >Yes we did vote on the spec as indicated in the posted draft meeting 
    >notes.  The documentation was presented to OASIS for submittal.  I 
    >provided the documents just as we reviewed them in that meeting. 
    >There were no corrections that came in after the call.  However, 
    >OASIS came back and requested a "red-lined" version of the changes. 
    >As you know, we reviewed a document without red lines but with a 
    >supplemental document that identified each and every change.  This 
    >is apparently not the approved submittal format for a 15-day review 
    >so, Patti is working to get the document in that form.
    >
    >I am glad this validation issue came up before the actual submittal 
    >and it needs to be worked out before the document is posted. 
    >Depending on the change(s) necessary, we may also have to vote on it 
    >again.  As we have agreed in the TC, it is more important to get it 
    >right than get it out there with errors.  We will have our regular 
    >full TC meeting on Tuesday 1/24 and will address any remaining 
    >issues.  Also, OASIS has schema experts that we can query about this 
    >issue if it is warranted.
    >
    >Regards,
    >Elysa
    >
    >At 04:03 PM 1/20/2006, Rex Brooks wrote:
    >>Hi Folks,
    >>
    >>Can someone clarify the status of the spec at this point? I had to 
    >>leave a bit before the end of the last TC meeting, and I thought we 
    >>were pretty much done. That would make this thread moot. Is that 
    >>incorrect?
    >>
    >>I tried to trace the thread back to get clarification that way, but 
    >>I got confused. I think that we may have had a case of one or 
    >>another of the comments being based on an incorrect "current" 
    >>version. I would really like to know where we stand at this point.
    >>
    >>Regards,
    >>Rex
    >>
    >>At 6:35 PM -0700 1/19/06, Ellis, David wrote:
    >>>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/>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>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>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>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..php
    >>
    >>
    >>--
    >>Rex Brooks
    >>President, CEO
    >>Starbourne Communications Design
    >>GeoAddress: 1361-A Addison
    >>Berkeley, CA 94702
    >>Tel: 510-849-2309
    >>
    >>---------------------------------------------------------------------
    >>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
    
    
    -- 
    Rex Brooks
    President, CEO
    Starbourne Communications Design
    GeoAddress: 1361-A Addison
    Berkeley, CA 94702
    Tel: 510-849-2309
    


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