W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

RE: Comments on WebArch

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 23 Feb 2004 14:24:02 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202B070ED@RED-MSG-30.redmond.corp.microsoft.com>
To: "David Orchard" <dorchard@bea.com>, <www-ws-desc@w3.org>

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Monday, February 23, 2004 1:53 PM
> To: Jonathan Marsh; www-ws-desc@w3.org
> Subject: RE: Comments on WebArch

> > 2.1: "The most straightforward way of establishing that two
> > parties are
> > referring to the same Web resource is to compare, as
> > character strings,
> > the URIs they are using."
> >
> > Double-check that we have a URI-comparison algorithm in place for
> > URIs we need to compare. Double-check our use of relative URIs is
> > reasonable and consistent.
> >
> On URI comp, I don't think we have to do anything because the scheme
> defines the comparison function.  For example, an HTTP URI has certain
> rules that the HTTP spec says.  We can't over-ride those rules.  We
> this in xlink, that is have xlink specific rules for comp, but I think
> that was a bad idea.

I note that for XML namespaces, we did indeed override those rules, and
say that XML namespaces are to be compared character-for-character.  Are
WSDL targetNamespaces more like URIs, or more like XML namespaces, for
the purpose of comparison?  I think we need to be explicit.  Likewise
XML namespaces can't (at least strongly shouldn't!) be relative.  Is
there a similar constraint for WSDL targetNamespaces?

> > 3.3.1: "Note that one can use a URI with a fragment identifier even
> > one does not have a representation available for interpreting the
> > fragment identifier (one can compare two such URIs, for example).
> > Parties that draw conclusions about the interpretation of a fragment
> > identifier without retrieving a representation do so at their
> > own risk;
> > such interpretations are not authoritative."
> >
> > This seems to imply that you can compare component
> > designators, but you
> > can't safely crack the URI and infer (for example) the type
> > of component
> > from it.  Do we need to say anything about that?
> >
> argh.  I think you CAN crack the URI IFF the WSDL spec defines how it
> them.  In the same way an HTML browser can populate a URI with FORM
> parameters because the HTML spec provides an authoritative mapping
> FORM to URI query string AND the origin server has chosen to use HTML,
> WSDL author can interpret and populate a URI that is contained within
> WSDL element IFF the WSDL spec provides authoritative rules for such.
> Somebody given an arbitrary URI in a document, say <foo
> link="somebodysWSDLURI"/> cannot just look at the URI and do
> interpretation of the URI UNLESS the <foo> vocabulary says "this link
> attribute IS A wsdl URI".

Although we don't actually use WSDL component designators in our
language (preferring QNames), I now see that other specs could indeed
crack a WSDL component designator URI since we define how such a URI is
constructed in the first place.  Consider my comment ill-considered!

> > 4.2.2: "Good practice: Namespace policy - Format designers SHOULD
> > document change policies for XML namespaces."
> >
> > Relates to our versioning issue: How do we allow WSDL users to
> > communicate the change policies for their namespaces (even though
> > aren't strictly XML namespaces)?
> >
> Why aren't they XML namespaces?  :-)  But seriously, I'm hoping that
> will provide the versioning attribute and then this will allow WSDL
> to communicate the cp policy.  And even if we don't, we should provide
> guidance to WSDL authors that they should document what they mean when
> namespace name either changes or doesn't under WSDL changes.

An XML namespace partitions XML elements and attributes.  A schema
targetNamespace is an XML namespace in that it partitions XML elements
and attributes, but also partitions complex and simple types and other
things.  A WSDL targetNamespace doesn't appear to properly be an XML
namespace at all, only partitioning WSDL components.  I agree there
should be as much similarity as possible, but it occurs to me that we
haven't said anywhere that WSDL namespaces obey all the same constraints
and best practices as XML namespaces, and we've crept far enough away
from XML namespaces that that would seems like a good thing to do.
Received on Monday, 23 February 2004 17:24:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:38 UTC