OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Brief Note RE: [emergency] RE: Question on EDXL-DE schema


FWIW,

I confirmed that if one substitutes "##other" for "##any" in the 
schema, it validates. Otherwise, it doesn't.

Ciao,
Rex

At 6:29 AM -0600 1/22/06, Elysa Jones wrote:
>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/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
>>
>>---------------------------------------------------------------------
>>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


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