Title: Re: [emergency] RE: Question on EDXL-DE schema
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:]
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/)
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#
>
>
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
---------------------------------------------------------------------
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
