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