OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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


We did vote on and approve the spec (the latest on the EM-TC site) as a
Committee Draft. This is an after-the-fact, but still needs to be
considered discussion.


Patti Iles Aymond, PhD
Senior Scientist
Bioterrorism Preparedness & Response

Innovative Emergency Management, Inc.
Managing Risk in a Complex World

8555 United Plaza Blvd.   Suite 100
Baton Rouge, LA 70809
(225) 952-8228 (phone)
(225) 952-8122 (fax)

-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Friday, January 20, 2006 4:04 PM
To: emergency@lists.oasis-open.org
Subject: RE: [emergency] RE: Question on EDXL-DE schema

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 

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.


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 and 
>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 
>>>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:
>>  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
>  > 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:
>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

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


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