Simon Fell > Its just code
Just in case you haven't seen them, here's the pictures from the dinner thursday night.
One concern I have over the move to doc/literal from rpc/enc [hey, its gonna happen, get over it], is that we don't subset XSD, XSD is pretty large, but the goal has to be to fully support it. For example, I suspect that support for xsd:choice is pretty slim on the ground.
Some thoughts and observations from the WSDL F2F. This is of course based on the tests I did, and the random set of conversations I had, YMMV.
- For the Document/literal tests, namespace qualification seemed to be a common issue, correctly getting the right mix of namespace qualified and not qualified elements and attributes based on the elementFormDefault & attributeFormDefault values, and whether a element definition is local or global. I'm glad I built on top of the MSXML 4.0 SOM for this one, which works all that out for you.
- For the rpc/encoded tests, generating the right type information, and resolving that informatation correctly. This seems to be compounded by a lack of clarity in the (SOAP) spec.
- Missing xsd:import's from schemas with cross schema references, a real common case (around 50% of the servers I tested), is forgetting to import the soap encoding namespace when defining section 5 arrays.
I fixed a number of minor problems, mostly related to all the special cases forced on you by section 5. I left with two more significant problems
- For doc/literal PocketSOAP treats all attributes as strings, so fails to apply the correct serialization for attributes with types such as xsd:boolean and xsd:dateTime.
- For soap encoded arrays of complex types, PocketSOAP will write an array type of xsd:anyType[x], this causes issues when the server is expecting a more strongly typed array. An array of complexTypes maps to an array of IUnknown pointers in PocketSOAP, so there's no specific type, this can only really be fixed by applying metadata during the serialization process.
The attributes problem is pretty straightforward, I coded up most of the fix for that during the flight home, this should clear up the set of compound1 failures. The array problem is fixable, there's already a place to store the metadata for this [in the serializerFactory mappings], its just a matter of changing the serialization code to take this metadata into account.
Of course there was the obligitory rpc/enc vs doc/literal discussions, In the past I've been a fan of rpc/enc but having now done a bunch of doc/literal stuff, I find doc/literal a much cleaner solution, rpc/enc's special cases that override XSD are a complete pain to work with. I hope that soap encoded either moves on to use XSD properly without special cases, or drops its use of XSD. I'd even settle for the encoding spec to clearly define the subset of XSD that it uses.