[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] RE: Question on EDXL-DE schema
Elysa, I still haven't heard back from Mary on what exactly a "red-lined" version means, so I haven't done any work toward that end. Hopefully, I'll get clarification today in time to make changes before the meeting tomorrow. Patti 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: Elysa Jones [mailto:ejones@warningsystems.com] Sent: Sunday, January 22, 2006 6:29 AM To: Rex Brooks; emergency@lists.oasis-open.org Subject: RE: [emergency] RE: Question on EDXL-DE schema 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/0 9/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.p hp>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..p hp >> >> >>--------------------------------------------------------------------- >>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.ph p>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..ph p > > >-- >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 > --------------------------------------------------------------------- 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 IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: http://www.ieminc.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]