Re: [SOAP] xsd:choice maxOccurs=unbounded, and element order

[email protected] (Simon Detheridge)
Newsgroups php.soap
Message-ID <[email protected]>
Actually the 'neat loophole' is a trick I stole from the official  
XHTML dtd. :-)

Having said that, I can remove the <xsd:sequence> elements entirely,  
so my schema looks something like:

<xsd:complexType name='containertype'>
   <xsd:choice maxOccurs='unbounded'>
     <xsd:element name='noun' type='nountype'>
     <xsd:element name='verb' type='verbtype'>
     <xsd:element name='other' type='othertype'>
   </xsd:choice>
</xsd:complexType>

The results are still the same. They elements come back grouped by type.

I've just tested this with my app to make sure that this is the case.

Simon

-- 
Simon Detheridge
SEN Developer, Widgit Software


Quoting "[email protected]" <[email protected]>:

>
> Thanks.  That example makes it clearer.
>
> I guess the problem is that the choice overrides the sequence.  With
> the repeating choice element you can have any order and that's valid
> even inside of the sequence.
>
> It is still inside a sequence though, so from the perspective of the
> parser, no matter what order the repeating choice elements are in, the
> parser should preserve that order.  Neat loophole you found there!
> You've found a way to make a sequence random!  Have you looked at
> putting in a tag other than sequence?
>
>
>
> On May 23, 2007, at 6:44 AM, Simon Detheridge wrote:
>
>> Quoting "[email protected]" <[email protected]>:
>>
>>> That structure is a bit confusing because of the repetition.
>>> Technically you could have any series of e1 elements and e2 elements
>> ...
>>> Your choice tag makes that possible.  Seeing that in a sequence tag
>>> seems strange.
>>
>> Actually, that's exactly what I want.
>>
>> It's not really as simple as in my example. The content actually   
>> describes a document which is broken up into different data types,   
>> but have to occur in the correct order in order to make sense.   
>> Let's try an example closer to what I'm trying to do:
>>
>> Say, instead of elements e1 and e2, I have three: 'noun', 'verb',   
>> and 'other'. (Again, this is a simplification, I'm not actually   
>> trying to do that, but my real-world schema is quite complicated   
>> and this is a better example)
>>
>> Say my document then looks like:
>>
>> <container>
>>  <other>The</other>
>>  <noun>cat</noun>
>>  <other>is</other>
>>  <verb>playing</verb>
>>  <other>with</other>
>>  <noun>string</noun>
>> </container>
>>
>> As far as I'm aware this is a perfectly OK thing to do with XML. I   
>> should be able to preserve my element order. (Hey, xhtml does stuff  
>>  quite similar to this, right?)
>>
>> Unfortunately, when it gets to PHP, I'm left with the following:
>>
>> [container] => stdClass Object
>>  (
>>    [noun] Array
>>      (
>>        [0] => cat
>>        [1] => string
>>      )
>>    [other] Array
>>      (
>>        [0] => playing
>>      )
>>    [verb] Array
>>      (
>>        [0] => The
>>        [1] => is
>>        [2] => with
>>      )
>>  }
>>
>> My original document which read "The cat is playing with string",   
>> now reads "cat string playing The is with", which doesn't make sense.
>>
>> Also, I'm not really in a position to muck around with the schema.   
>> It's working in a couple of implementations. Dotnet (which   
>> unfortunately is what most people seem to want to use to talk to   
>> this thing) handles the above case fine. I really need something to  
>>  happen at the PHP-client end, in order to make this work.
>>
>> I still think it looks like a bug.. ?
>>
>> Simon
>>
>> -- 
>> Simon Detheridge
>> SEN Developer, Widgit Software
>>
>>
>> Quoting "[email protected]" <[email protected]>:
>>
>>>
>>> That structure is a bit confusing because of the repetition.
>>> Technically you could have any series of e1 elements and e2 elements
>>> like this:
>>>
>>> <container>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e1>some_stuff</e1>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e1>some_stuff</e1>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e1>some_stuff</e1>
>>> 	<e1>some_other_stuff</e1>
>>> 	<e1>some_stuff</e1>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e1>some_stuff</e1>
>>> 	<e2>different_other_stuff</e2>
>>> </container>
>>>
>>> Your choice tag makes that possible.  Seeing that in a sequence tag
>>> seems strange.  Perhaps you should not use the sequence.  That says
>>> that elements are ordered in a specific order.  I don't know if the
>>> choice tag interrupts that ordering.  If the sequence applies then it's
>>> going need to be like this in order to validate:
>>>
>>> <container>
>>> 	<e1>some_stuff</e1>
>>> 	<e1>some_stuff</e1>
>>> 	<e1>some_stuff</e1>
>>> 	<e1>some_other_stuff</e1>
>>> 	<e1>some_stuff</e1>
>>> 	<e1>some_stuff</e1>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> 	<e2>different_other_stuff</e2>
>>> </container>
>>>
>>> If there is a relationship between e1 and e2 and they have to appear as
>>> a pair, then you might consider wrapping them in a complex type with a
>>> sequence and just putting minOccurs=0 and maxOccurs="unbounded" on the
>>> element of that type.
>>>
>>>
>>>
>>>
>>> On May 23, 2007, at 4:32 AM, Simon Detheridge wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry for crossposting. I sent this to php-general yesterday, not  
>>>>   realising there was a specific SOAP list...
>>>>
>>>> I'm trying to make PHP5's soap implementation play nice with my   
>>>> web  service, and I'm
>>>> having a problem.
>>>>
>>>> Part of my schema contains a complexType, containing an   
>>>> xsd:choice  of several different
>>>> element types, which can be repeated many times (maxOccurs=unbounded)
>>>>
>>>> e.g.:
>>>>
>>>> <xsd:complexType name='containertype'>
>>>> <xsd:sequence>
>>>>   <xsd:choice maxOccurs='unbounded'>
>>>>     <xsd:element name='e1' type='e1type'>
>>>>     <xsd:element name='e2' type='e2type'>
>>>>   </xsd:choice>
>>>> </xsd:sequence>
>>>> </xsd:complexType>
>>>>
>>>> The problem is that the order of element here is important. I   
>>>> want  the results returned
>>>> in the same order that they appear in the XML.
>>>>
>>>> Unfortunately, what I end up with, is an object containing an   
>>>> array  of all the e1
>>>> elements, followed by an array of all the e2 elements.
>>>>
>>>> Take the following example... If there following were in my soap result:
>>>>
>>>> <container>
>>>> <e1>some_stuff</e1>
>>>> <e2>different_stuff</e2>
>>>> <e1>some_other_stuff</e1>
>>>> <e2>different_other_stuff</e2>
>>>> </container>
>>>>
>>>> What I actually end up seeing is something like:
>>>>
>>>> [container] => stdClass Object
>>>> (
>>>>   [e1] Array
>>>>     (
>>>>       [0] => some_stuff
>>>>       [1] => some_other_stuff
>>>>     )
>>>>   [e2] Array
>>>>     (
>>>>       [0] => different_stuff
>>>>       [1] => different_other_stuff
>>>>     )
>>>> }
>>>>
>>>> Note that this is somewhat simplified from my real-world example.  
>>>>   In reality, "e1" and
>>>> "e2" are complexTypes themselves.
>>>>
>>>> But I really do need to see the resulting elements in the same    
>>>> order that they were
>>>> supplied. I'm able to do this in dotnet and gsoap clients, so   
>>>> far.  (I haven't tried any
>>>> others.)
>>>>
>>>> Incidentally, I'm using a basic unmodified skeleton generated by   
>>>>  wsdl2php as my classmap.
>>>> The object describing the 'container' type looks simply like:
>>>>
>>>> class container {
>>>> }
>>>>
>>>> Perhaps it's possible to add something to this to help sort the   
>>>> order out??
>>>>
>>>> Any suggestions are appreciated. Could this be a bug?
>>>>
>>>> Incidentally, the full-blown (and rather complicated I'm afraid)   
>>>>  schema/wsdl for what I'm
>>>> *actually* trying to do is at    
>>>> http://www.widgit.com/cml/symgate.wsdl if that helps.
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>> -- 
>>>> Simon Detheridge
>>>> SEN Developer, Widgit Software
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE:
>>>> This email and any attachments are for the exclusive and    
>>>> confidential use of the intended recipient.  If you are not the    
>>>> intended recipient, please do not read, distribute or take action  
>>>>   in reliance upon this message. If you have received this in   
>>>> error,  please notify us immediately by return email and promptly  
>>>>  delete  this message and its attachments from your computer  
>>>> system.
>>>>
>>>> Logotron is a limited company registered in England, number    
>>>> 04113866. The registered office is Logotron Ltd, 124 Cambridge    
>>>> Science Park, Milton Road, Cambridge, CB4 0ZS.
>>>>
>>>> --
>>>> PHP Soap Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>
>>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.