Re: The WSDL 2.0 XSD for Root Element is Too Loose

Roberto/Asir,

I agree that the <choice> approach is awkward (although it could be fixed 
to address (a) and (b)), but I'd like to drop that suggestion and offer a 
much cleaner and simpler one.

I am assuming that we really do want to enforce the order of the top level 
elements. The structure of a WSDL document then really has 3 parts:

1. A "prelude" where we import and include other documents. (This could 
also be called a prolog, preamble, head, header, etc.)
2. A "types" section where we define XML types, and
3. A "components" section where we define Web service components (This 
could also be called the body)

So why not introduce two new, optional, top level elements, and have the 
following schema:

<description>
        <prelude>?
        <types>?
        <components>?
</description>

<prelude>
        (<import> | <include> | extension)+
</prelude>

<components>
        (<interface> | <binding> | <service> | extension)+
</components>

This has the following advantages:
1. It enforces the order via the schema
2. It is human-readable
3. It is code generator friendly
4. It is deterministic
5. It is consistent with the current <types> element which collects 
together the XML type definitions
6. It is similar to HTML which has a <head> and <body>
7. It makes no change to the component model

Arthur Ryman,
Rational Desktop Tools Development

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.ca
intranet: http://labweb.torolab.ibm.com/DRY6/



Roberto Chinnici <Roberto.Chinnici@Sun.COM> 
01/10/2005 04:33 PM

To
Asir Vedamuthu <asirv@webmethods.com>
cc
Arthur Ryman/Toronto/IBM@IBMCA, public-ws-desc-comments@w3.org, Vlad 
Klicnik/Toronto/IBM@IBMCA
Subject
Re: The WSDL 2.0 XSD for Root Element  is Too Loose






Asir Vedamuthu wrote:

> Arthur,
> 
>> The above grammar is deterministic and enforces the ordering
>> constraint expressed in the spec using XSD constructs
> 
> Yes, it is deterministic. Yes, it enforces the ordering constraints. 
> But, at a cost (at a glance):
> 
> (a) rules out extensibility elements
> (b) types element is required if either include or import element is 
> present
> (c) .. so on

(d) A XSD->Java tool will generate yucky code when it encounters it. 
(Most tools will,
regardless of the target language. <xsd:choice/> is just too hard to 
translate.)

>> I am in favour of expressing as many as possible constraints in XSD
> 
> I agree with you, whenever feasible.

I don't. I'd rather have a human-readable schema than a complete one,
especially given we can't make it 100% accurate.

Roberto

Received on Tuesday, 11 January 2005 18:30:21 UTC