Bottom line? don't throw an error with the wsrf wsdl. right? -- dims
On 8/24/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > On Wed, 2005-08-24 at 09:19 -0400, Glen Daniels wrote: > > Dims, you can only do that if WSDL says that's what you do (otherwise > > it's not interoperable, or correct according to schema). > > > > I don't see the problem Sanjiva is worried about, though. If the > > elements are unqualified, then the references are simply unqualified as > > well... <input element="foo"/> instead of <input element="ns:foo"/> - > > what's the big deal? > > The rules for resolving qualified *values* that WSDL 1.1 assumed came > from XSLT, not from WSDL. (See http://www.w3.org/TR/xslt#qname.) So > while you're correct about how one could interpret > element="foo" (because XSDL explicitly states that default NS doesn't > apply), it was not the intent of WSDL 1.1 that unqualified names would > be used as values of @element and @type. Furthermore, WSDL 1.1, does not > specify or imply the behavior you propose. > > For those of you who care about the WS-I Basic Profile, it clarifies > this issue too: > > http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16552904 > > However, the solution they advocate (which is what the WS-RF schema > uses) is actually incorrect w.r.t. XSD IMO .. the EIIs and AIIs defined > in the schema which is imported inside another schema are not visible > outside of the enclosing schema. So in other words, WSDL would not be > able to see them. WS-I BP gets around that by defining its own rules .. > but technically that's not correct. > > Anyway, I take back my previous comment: this *specific style of XSDs* > (per the WS-I BP clarification) should be supported as a special case. > The style being of course: > <xsd:schema> > <xsd:import namespace=".." location=".."/> > </xsd:schema> > This is analogous to what we allow in WSDL 2.0 by allowing xsd:import > directly as a child of wsdl:types. > > We clarified this whole issue in WSDL 2.0 after lots of thought. See: > http://www.w3.org/TR/2005/WD-wsdl20-20050803/#xsd-types > > There we say (in 3.1.1.1): > > "The namespace attribute information item defines the namespace of the > element declarations and type definitions imported from the referenced > schema. The referenced schema MUST contain a targetNamespace attribute > information item on its xs:schema element information item and the > values of these two attribute information items MUST be identical. It is > an error to import a schema that does not have a targetNamespace > attribute information item on its xs:schema element information item. > Such schemas must first be included (using xs:include ) in a schema that > contains a targetNamespace attribute information item on its xs:schema > element information item, which can then be either imported or inlined > in the WSDL 2.0 document." > > === > > In WSDL 1.1, the trick we used was to say you can use WSDL 1.1's > <import> element to import XSDs. (See Section 2.1.2 of > http://www.w3.org/TR/wsdl.) So the right way to do the above would've > been to write: > <wsdl:definitions ...> > > <wsdl:import namespace=".." location=".."/> > .. > </wsdl:definitions> > > The WSDL processor was responsible for sniffing the stuff at the > location URI and figuring out whether to import it as XSD or as WSDL (or > some other type system .. in the WSIF context people have used it to > import weirdities like COBOL copy books ;-)). > > However, WS-I BP folks, in their infinite wisdom, felt this was no good > and declared this illegal: > > http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16498504 > > (It baffles me how WS-I BP folks felt they could re-write the WSDL 1.1's > recommended authoring style (http://www.w3.org/TR/wsdl#_style) but > that's what they did. Oh well.) > > Sanjiva. > > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
