Proposal for Resolution of CR005

Here is my proposal for resolving CR005 [1].

The issue is that the spec currently says that a WSDL document does not 
need to <xsd:import> the XSD namespace when it refers to it components in 
it [2], but the spec doesn't say if those components are always present in 
the WSDL component model.

A WSDL 2.0 document MUST NOT refer to XML Schema components in a given 
namespace unless an xs:import or xs:schema element information item for 
that namespace is present or the namespace is the XML Schema namespace 
which contains built-in types as defined in XML Schema Part 2: Datatypes 
Second Edition [XML Schema: Datatypes]. 

In fact, the only built-in types defined by XML Schema are the simple 
datatypes like xs:string, xs:int, etc., and the only WSDL components that 
could possibly references these are Property components via the {value 
constrain} property.[3] For example, suppose you want to define a Property 
that has a xsd:string value.

<property ref="http://example.org/property/foo">
        <constraint>xs:string</constraint>
</property>

The spec says the WSDL  document does not have to <xs:import> 
http://www.w3.org/2001/XMLSchema 

This exception was introduced as a simplification for authors because I 
thought authors would frequently refer to the built-in types. But in fact 
they are only references from Property components and authors might well 
define there own types anyway to express additional constraints, e.g. 
using facets. 

There are two possible resolutions.

R1 - remove the exception so that document do have to import the XML 
Schema namespace. This means that any document that references the XML 
Schema built-in types would have to include a section like:

<type/>
        <xs:import namespace="http://www.w3.org/2001/XMLSchema " />
</type>

R2 - add a statement to the state stating that every component model 
contains the built in types. I would add the following statement to 2.1.1 
The Description Component

The {type definitions} property of the Description component MUST contain 
all of the built-in datatypes defined by XML Schema Part 2: Datatypes 
Second Edition [XMLSchema: Datatypes] [4], namely string, boolean, 
decimal, float, double, duration, dateTime, time, date, gYearMonth, gYear, 
gMonthDay, gDay, gMonth, hexBinary, base64, Binary, anyURI, QName, 
NOTATION, normalizedString, token, language, NMTOKEN, NMTOKENS, Name, 
NCName, ID, IDREF, IDREFS, ENTITY, ENTITIES, integer, nonPositiveInteger, 
negativeInteger, long, int, short, byte, nonNegativeInteger, unsignedLong, 
unsignedInt, unsignedShort, unsignedByte, positiveInteger.

After reflection on this issue, I recommend R1 because I don't think it is 
really much of a burden to authors to add the <xs:import> in those cases 
where they actually define Property components that directly reference 
built-in XML Schema types.. It makes the spec simpler since there are no 
exceptions to the import rule. It makes the component model simpler since 
it removes some of the coupling with XML Schema.


[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR005
[2] http://www.w3.org/TR/2006/CR-wsdl20-20060106/#xsd-types
[3] 
http://www.w3.org/TR/2006/CR-wsdl20-20060106/#property-Property.valueconstraint
[4] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-datatypes

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.c