Hi, I've had an interesting chat with Richard Opalka today regarding the way CXF builds the Metadata part of the (WSA) EPR. Particularly, at the moment, CXF does something like this :
<Metadata wsdli:wsdlLocation='http://localhost:8080/hello?wsdl' xmlns:wsdli='http://www.w3.org/ns/wsdl-instance'>...</Metadata> Richard pointed me to the relevant section of the WSDL 2.0 spec which also mentions WSDL 1.1. According to that section, @wsdlLocation is expected to contain pairs similarly to the way an xsi:schemaLocation attribute does, ex, wsdli:wsdlLocation='http://helloservice <http://localhost:8080/hello?wsdl> http://localhost:8080/hello?wsdl' where "http://helloservice"; is the target namespace of the referenced WSDL instance. I'm not understanding where this requirement to have the pairs come from originally (i.e, a given service endpoint is described by a single WSDL doc (which may import few others) as opposed to a xml instance validation depending on a number of schemas being available) and at least on the surface the first value is redundant, but it needs to be fixed anyway because there's a "MUST" bit in [1]. I would not even worry if it were "SHOULD". My question is : can it be that CXF omits the target namespace (such as http://helloservice) for a reason ? Example, can we have legacy consumers parsing a wsdlLocation attribute manually and assuming its value is a location only as opposed to a pair of targetNs/location ? I don't recall now but I vaguely remember I was doing some manual parsing of the returned EPRs awhile back... Do any users out there have the applications depending on this attribute ? I'm just wondering how to fix it. I guess the contextual property can be introduced if there's a concern that fixing it can lead to backward-compatibility issues... cheers, Sergey [1] http://www.w3.org/TR/2007/REC-wsdl20-20070626/#wsdlLocation-aii
