Return-Path: 
 <issues-return-12953-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: (qmail 41381 invoked from network); 19 Feb 2010 01:18:58 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 19 Feb 2010 01:18:58 -0000
Received: (qmail 77035 invoked by uid 500); 19 Feb 2010 01:18:58 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 76989 invoked by uid 500); 19 Feb 2010 01:18:58 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 76979 invoked by uid 99); 19 Feb 2010 01:18:58 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Feb 2010 01:18:57 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Feb 2010 01:18:49 +0000
Received: from brutus.apache.org (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id E264029A0016
	for <issues@cxf.apache.org>; Thu, 18 Feb 2010 17:18:27 -0800 (PST)
Message-ID: <1068607054.376151266542307925.JavaMail.jira@brutus.apache.org>
Date: Fri, 19 Feb 2010 01:18:27 +0000 (UTC)
From: "Dennis Sosnoski (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Commented: (CXF-2680) wsdlvalidator ignores WSDL constraints
 on element order
In-Reply-To: <2070745099.353871266489928472.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/CXF-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835540#action_12835540 ] 

Dennis Sosnoski commented on CXF-2680:
--------------------------------------

Though I now see that WS-I BP references yet another version of the WSDL 1.1 schema: http://ws-i.org/profiles/basic/1.1/wsdl-2004-08-24.xsd It might be worth switching to that one, since it looks like it includes more fixes.

> wsdlvalidator ignores WSDL constraints on element order
> -------------------------------------------------------
>
>                 Key: CXF-2680
>                 URL: https://issues.apache.org/jira/browse/CXF-2680
>             Project: CXF
>          Issue Type: Bug
>          Components: Tooling
>    Affects Versions: 2.2.5
>            Reporter: Dennis Sosnoski
>         Attachments: library-plain.wsdl
>
>
> When running WSDLToJava with the -validate flag a WSDL with elements in incorrect order is accepted without complaint. In the example tested, the wsdl:service element precedes the wsdl:types element. This is a violation of the WSDL 1.1 schema definition, which defines the wsdl:definitions element structure as:
>    <complexType name="definitionsType">
>       <complexContent>
>          <extension base="wsdl:documented">
>             <sequence>
>                <element ref="wsdl:import" minOccurs="0" maxOccurs="unbounded"/>
>                <element ref="wsdl:types" minOccurs="0"/>
>                <element ref="wsdl:message" minOccurs="0" maxOccurs="unbounded"/>
>                <element ref="wsdl:portType" minOccurs="0" maxOccurs="unbounded"/>
>                <element ref="wsdl:binding" minOccurs="0" maxOccurs="unbounded"/>
>                <element ref="wsdl:service" minOccurs="0" maxOccurs="unbounded"/>
>                <any namespace="##other" minOccurs="0" maxOccurs="unbounded">
>                   <annotation>
>                      <documentation>to support extensibility elements </documentation>
>                   </annotation>
>                </any>
>             </sequence>
>             <attribute name="targetNamespace" type="uriReference" use="optional"/>
>             <attribute name="name" type="NMTOKEN" use="optional"/>
>          </extension>
>       </complexContent>
>   </complexType>
> If there's going to be a -validate flag it should perform a proper validation of the WSDL. I realize it's common for implementations to accept invalid WSDL of this type, but there should at least be a warning generated so that users will realize their WSDL is not actually valid.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.