http://www.w3.org/TR/xmlschema-0/
read section 2.2.1 . Even if you declare a default attribute for an element, you need to return it to set its content node to the default value. This might be off the scope of this list but what I fail to understand is that when you have defined your message type in an XSD and if your webservice code is bound to it for validation, then how is it able to send a soap response which would violate the message structure. Can you let me know the server - side language? ~Peeyush On Tue, Mar 4, 2008 at 7:13 PM, Todd <[EMAIL PROTECTED]> wrote: > It's not the exact schema, but it does look just like it, especially > without the minoccurs and maxoccurs. > > I've also tried setting the minoccurs=0 (but didn't set the maxoccurs) > with similar results. Maybe need to set both minoccurs and maxoccurs? > > I couldn't find anywhere in the XSD docs where it talks about the > default occurence attributes are either set, nor any docs telling me > what they default to. Do you have a link? What I have found are > little sentence blurbs at the W3C site, like this: "5.5 Default Values > - An omitted accessor element implies either a default value or that > no value is known. The specifics depend on the accessor, method, and > its context. For example, an omitted accessor typically implies a Null > value for polymorphic accessors (with the exact meaning of Null > accessor-dependent). Likewise, an omitted Boolean accessor typically > implies either a False value or that no value is known, and an omitted > numeric accessor typically implies either that the value is zero or > that no value is known." > > Reading this leads me to believe that not returning elements implies > that their values are just default/null. > > > --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "Peeyush > Tuli" <[EMAIL PROTECTED]> wrote: > > > > In your xsd there are no occurence attributes specified > > , so the elements have default occurrence attributes, > > > > minoccurs=1 and maxoccurs = 1 > > > > In other words, they are always required once. Are you sure this is the > > exact > > schema which defines your response element? > > > > ~Peeyush > > > > On Tue, Mar 4, 2008 at 3:05 AM, Todd <[EMAIL PROTECTED]> wrote: > > > > > Hello, > > > When I'm decoding a call to a Soap Service, I'm finding that if the > > > soap response is missing a few elements, then the rest of the itmes > > > don't get parsed from a sequence. Is this expected behavior? > > > > > > Say, I have a XSD element declared like so: > > > <complexType name="CommunicationType"> > > > <sequence> > > > <element name="id" type="long"/> > > > <element name="version" type="int"/> > > > <element name="name" type="string"/> > > > <element name="description" type="string"/> > > > <element name="recordCount" type="int"/> > > > ... > > > </sequence> > > > </complexType> > > > > > > If the Soap Response looks similar to: > > > <Communication > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";> > > > <name> > > > EmailCommunicationTemplate > > > </name> > > > <description> > > > email communication template > > > </description> > > > <recordCount> > > > 0 > > > </recordCount> > > > ... > > > </Communcation> > > > > > > I'm finding that all the properties on the Object returned to my > > > result handler aren't populated with anything because as you see, > > > there was no id, or version, returned from the Soap Response. > > > > > > However, in the Schema, these aren't declared required or anything. > > > When I add an id into the Soap Response, then the object being > > > returned will have a valid ID set, but nothing else. I'm assuming > > > that the default SoapDecoder (XMLDecoder) maps properties up until the > > > first one that is missing. > > > > > > Is flex Soap Services implying that for a Sequence type, every node > > > must be returned, even if nil? Is this a standard? Any known work > > > arounds? (I searched JIRA and just found a ton of things not related > > > to me.) > > > > > > (I'm also getting tired of mapping XML off the wire to object by > hand.) > > > > > > Thanks, > > > Todd > > > > > > > > > > > > > >
