Thanks for the prompt reply, Gary H,
I read through the recommended change, and although I would like to hear
what Art, Jacob, Don M, Jeff W, Dave E and Lee T think, along with any
others who wish to pipe up, I think I could live with it. Either
adopting this change or dropping the <any>s in favor of the CAP v1.1
formulation will still require a new Review Process, so unless someone
can show me how this would not require a new 60-Day Review, we're still
looking at a substantial delay. The good news is that I don't think this
would require a change in the CAPv1.2-IPAWS Profile.
Cheers,
Rex
Gary Ham wrote:
> Folks,
>
> Based on Neil's difficulties with Web service compilers, Gary Timm's
> message, and on Rex Brook's response asking for a solution that does
> not break the ability to make the change a 1.2 version vice forcing
> 2.0 , I decided maybe we should in fact look at a solution that does
> work as a 1.2 change. We have tested this with out a problem and know
> that it works. The basic concept is to encapsulate the <any> tags
> within optional identified tags to isolate them from multi-namespace
> issues. (For backward compatibility we could also leave the current
> 1.1 <any> tag in place, but we would not make any use of it.)
>
> I know it is late in the game. But the following change would make
> signing work in web services and middleware validation points far more
> effectively than the current structure of CAP 1.2. That and a
> requirement that message signature use XML canonical form (as required
> in the DE) and we could guarantee success across the network. Neil has
> tested this change and it does work.
>
>
> Respectfully,
>
> Gary
>
>
> Begin forwarded message:
>
>>
>> *From:* Bourgeois, Neil
>> *Sent:* Wednesday, February 03, 2010 5:13 PM
>> *To:* Gary Ham
>> *Subject:* CAPv1.2 Web-Service Implementation Challenges
>>
>> Gary,
>> We are experiencing Web-service implementation issues with the
>> CAPv1.2 schema. DM-OPEN is currently using Oracle 10g application
>> server and Oracle 10g assembler to generate Web-Services. DM-OPEN is
>> also leveraging JAXB2 and its capabilities in binding XML to Java
>> classes.
>>
>> Here are the following issues:
>> 1) With the two <any.../> tags the Oracle Assembler generates a
>> single Alert object as a SOAP Element. This will require a
>> significant amount of rework to upgrade the current CAPv1.1
>> Web-Service to CAPv1.2.
>> 2) JAXB will not compile. Get response that "Any element has already
>> been defined".
>>
>> Recommendation to resolve these issue is to place <any.../> elements
>> within their own element. This is also a more mature schema structure.
>>
>> Have similar Web-Service implementation issues been experienced by
>> other developers?
>>
>>
>> Neil Bourgeois
>> /Cell: 703-732-6331/
>>
>>
>> Original Schema:
>> </element>
>> <any minOccurs = "0" maxOccurs = "unbounded"
>> namespace = "http://www.w3.org/2000/09/xmldsig#
>> <http://www.w3.org/2000/09/xmldsig>" processContents = "lax"/>
>> <any minOccurs = "0" namespace =
>> "http://www.w3.org/2000/09/xmlenc#
>> <http://www.w3.org/2000/09/xmlenc>" processContents = "lax"/>
>> </sequence>
>> </complexType>
>> </element>
>> <element name = "valueName" type = "xs:string"/>
>> <element name = "value" type = "xs:string"/>
>> </schema>
>>
>> Recommended Change:
>> </element>
>> <element ref="cap:Signature"/>
>> <element ref="cap:Encoding"/>
>> </sequence>
>> </complexType>
>> </element>
>> <element name="Signature">
>> <complexType>
>> <sequence>
>> <any minOccurs = "0" maxOccurs = "unbounded" namespace =
>> "http://www.w3.org/2000/09/xmldsig#
>> <http://www.w3.org/2000/09/xmldsig>" processContents = "lax"/>
>> </sequence>
>> </complexType>
>> </element>
>> <element name="Encoding">
>> <complexType>
>> <sequence>
>> <any minOccurs = "0" namespace =
>> "http://www.w3.org/2000/09/xmlenc#
>> <http://www.w3.org/2000/09/xmlenc>" processContents = "lax"/>
>> </sequence>
>> </complexType>
>> </element>
>> <element name = "valueName" type = "xs:string"/>
>> <element name = "value" type = "xs:string"/>
>> </schema>
>>
>
> Gary Ham
> Systems Architect
> FEMA Disaster Management Program
> 703-899-6241
>
>
> Gary Ham
> http://grandpaham.com
> 703-899-6241
>
>
>
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
