W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2002

Re: Arguments for keeping R120

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 30 Sep 2002 12:10:10 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Philippe Le Hegaret <plh@w3.org>, Arthur Ryman <ryman@ca.ibm.com>, www-ws-desc@w3.org
Message-ID: <20020930121010.A779@w3.org>

On Mon, Sep 30, 2002 at 07:52:45AM -0700, Martin Gudgin wrote:
> I'm not sure that what XSD did was actually bad. It forces us to be
> explicit about what we want to refer to. You have to have context to
> know what it is at the end of a reference.

My point is that there are some existing tools and many more we can
imagine that use an identifier for a single web resource get the type
information along with the resource (representation). This approach
allows us to use caches and search tools and lots of other things to
assist applications they know nothing about.

>                                            If you don't have context,
> you can't really know ( and maybe you don't care ). What XSD does ( and
> WSDL follows suit ) is state that the context of the reference
> determines the type. And WSDL uses the element and type attributes for
> different things right now. I'm not sure how having a single attribute
> would actually help processors.

While changing XSD is wayyy out of scope, it bears pointing out that
the meta advantages of having URI identifiers for WSDL also apply to
XSD and any other web application. The trust/endorsement examples [2]
may not apply as well, but the IPR managements [3] ones could be
desirable to lots of XSD users. And there are scads more that would
seem as imfeasible today as a search engine did before alta vista.

So what? Any data we make addressable a via will be a help. So maybe
we lose the use of these application-naive utilities for working with
the portions of the included schema. I think it's more likely we will
want to describe, for instance, P3P policies on a binding than on a
piece of schema.

Or we could impose furthur constraints on XSD used for WSDL, maybe
backing off to a SHOULD (or maybe a MIGHT, which I think is underused
in normative texts).

> > -----Original Message-----
> > From: Philippe Le Hegaret [mailto:plh@w3.org]
> > Sent: 27 September 2002 14:49
> > To: Arthur Ryman
> > Cc: www-ws-desc@w3.org
> > Subject: Re: Arguments for keeping R120
> > 
> > 
> > 
> > On Fri, 2002-09-27 at 17:03, ryman@ca.ibm.com wrote:
> > > 
> > > Eric,
> > > 
> > > WSDL syntax is modelled on XSD in the sense that in XSD you
> > can have a
> > > type and an element that have the same name. What is the
> > recommended
> > > solution for XSD? Shouldn't WSDL follow that for simplicity?
> > 
> > And we ended up having a type attribute and an element
> > attribute in the WSDL part element, so I don't think that 
> > following XSD here sets a good example at all. A proposal for 
> > simplicity [1] advocates to add a complexType wrapper element 
> > construction in WSDL in order to eliminate the element 
> > attribute. We cannot change XSD but we can still change WSDL.
> > 
> > Philippe
> > 
> > [1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0055.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0082.html line 71
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0082.html line 78


office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Monday, 30 September 2002 12:10:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:39 UTC