RE: Comments on WebArch

> -----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
any
> > 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
did
> 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
if
> > 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
uses
> them.  In the same way an HTML browser can populate a URI with FORM
> parameters because the HTML spec provides an authoritative mapping
from
> FORM to URI query string AND the origin server has chosen to use HTML,
a
> WSDL author can interpret and populate a URI that is contained within
a
> 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
they
> > aren't strictly XML namespaces)?
> >
> 
> Why aren't they XML namespaces?  :-)  But seriously, I'm hoping that
we
> will provide the versioning attribute and then this will allow WSDL
users
> 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
a
> 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