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


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


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