[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code generation
> You've left out a vital part of the example, that being the minoccurs > attributes. Without them, the example doesn't make sense - there would > be no reason for creating such an ugly construct. I think it > should look > like: > > <choice> > <element name="one" type="string" minoccurs="1"/> > <sequence> > <element name="one" type="string" minoccurs="0"/> > <element name="two" type="string" minoccurs="1"/> > </sequence> > </choice> Yes, you're right. I was concentrating on the bit that caused the problem rather than the context... > > I really dislike this idiom, which is a nasty hack to support the idea > that we require at least one object, where that one may be chosen from > two types. It requires that the schema parser be coded with special > handling for this oddball construct. <snip> Maybe I was a little hasty in saying that this is something we should expect the parsers/WSDL kits to get right, but something that needs to be addressed in the UDDI WSDL. I don't expect an answer here and now, but this is the sort of scrutiny I think the UDDI WSDL needs - is there a simpler way of expressing the same thing (probably no in this case); is there a simpler construct which expresses almost the same thing (and is acceptible) (arguable in this case, but hopefully a consensus could be reached). In the latter case I don't think we should diverge into two schemas though, for the reasons I mentioned before. Matthew
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]