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