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