John, In the W3C WG, we discussed enforcing the order and cardinality of elements under the <description> element and decided not to enforce it in the schema. The reason is that the schema gets very complicated (at least to enforce the order).
It might be OK to enforce the occurence of the <types> element. However, I'd recommend we just add an assertion to enforce this. -- Arthur On 8/8/07, John Kaputin (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/WODEN-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518375 > ] > > John Kaputin commented on WODEN-141: > ------------------------------------ > > I think there is still a problem how Woden handles the wsdl:types element, > but it's tied to a problem with the WSDL 2.0 spec so I will raise a bugzilla > against the spec and hopefully the new W3C Web Services core working group > being formed around September 2007 will address it. > > The problem with Woden is that it throws a 'duplicate types element' > WSDLException if DescriptionElement.addTypesElement is called more than once. > This means that parsing will stop on this error. The general behaviour of > Woden is to parse the entire WSDL document, even if it has errors, report any > schema validation errors or, if no schema errors exist, then to validate ALL > wsdl assertions and report any assertion errors. That is, woden doesn't stop > parsing when it hits a WSDL error. However, it will now stop parsing if a > wsdl:description element contains more than one wsdl:types element. > > The problem with the spec is that the WSDL 2.0 schema permits multiple > wsdl:types element, so we can't detect this error during schema validation. > And although the spec states that the wsdl:description may have only ONE > wsdl:types element, it does not capture an assertion for this, so at the > moment we can't pick up this error via assertion validation. > > I think the solution might be to change the WSDL 2.0 schema to restrict > wsdl:description to a single wsdl:types element. I'll report this via W3C > bugzilla for now. This JIRA can remain 'resolved'. I will open a new Woden > JIRA to keep track of the bugzilla and any follow-up woden action required. > > > DescriptionElement.getTypesElement() should not be a factory method > > ------------------------------------------------------------------- > > > > Key: WODEN-141 > > URL: https://issues.apache.org/jira/browse/WODEN-141 > > Project: Woden > > Issue Type: Bug > > Components: Parser > > Reporter: John Kaputin > > Assignee: Dan Harvey > > Fix For: M8 > > > > Attachments: BaseWSDLReader.java.2.patch, > > BaseWSDLReader.java.patch, DescriptionElement.java.patch, > > DescriptionImpl.java.2.patch, DescriptionImpl.java.patch, > > DescriptiontElementTest.java.patch, DescriptionTest.java.patch, > > DOMWSDLReader.java.patch, Messages.properties.patch, > > WSDLDocumentValidatorTest.java.patch > > > > > > The behaviour of the DescriptionElement.getTypesElement() method is to > > return the types element if it exists or if not, create it and return it. > > This means that the model can never reflect an infoset that does not have a > > <wsdl:types> element because this getter method will always create one even > > if there isn't one in the WSDL. > > Instead, this method should return null if there is no types element and a > > new factory method is required - createTypesElement(), which will create a > > TypesElement, set the DescriptionElement as its parent and return a > > reference to it. This is similar behaviour to the addXXXXElement methods > > that create sets of child elements, except that it acts on a single types > > element only (hence the method name 'create' rather than 'add'). > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
