RE: Schematron schema for SOAP 1.1 Envelopes

Your point #1 is incorrect.  Same with #2.  A namespace identifier is a URI
so that the namespace can be guaranteed unique across a namespace.  The
definer of a namespace will probably pick a URI as it's dependent upon DNS
which is dependent upon IP, so there is some guarantee of uniqueness.
Indeed, the namespace 1.0 spec as written allows you to put any characters
in there, URI or not.

It's careless to make an assumption - namespaces are URIs for the purpose of
fetching schemas - and then claim it as fact.  It has never been the intent
that applications can do a GET on the namespace URI to fetch a schema.

Eventually, there will be a packaging specification that deals with all the
relevent information for a document - schemas, xslt, xinclude targets,
xlinks, xlink targets, gifs, ....  Then there can be a mechanism for
retrieving the related documents.  But it's very much not a namespace issue.
The W3C has done an excellent job of not coflating identity with packaging
with location.  It has done a terrible job of defining identity.

Cheers,
Dave Orchard



-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Henrik Frystyk Nielsen
Sent: Wednesday, September 20, 2000 7:39 AM
To: Rick JELLIFFE; xml-dist-app@w3.org
Subject: RE: Schematron schema for SOAP 1.1 Envelopes


> 1) A namespace is not a schema. I would hope XML namespaces will
> eventually get some mechanism for being useful for reliable retrieval
> semantic schemas (and also other kinds of resources appropriate to the
> namespace).  It would not enter my mind to expect an XML Schema at the
> other end of a namespace.

That's too bad because that is why a namespace identifier is a URI -
depending on the type of URI you might get the change to perform a GET on
it using some protocol and you might get a schema when doing so.

> 2) I would, however, look for it at the end of an xsi:schemaLocation
> attribute.  I did not recall the text expressing that there
> was a schema
> at the other end of the link.  I would assume that the spec
> itself would
> be at the other end, if anything (i.e., for when the spec or
> a paragraph
> is cut and pasted out, and one wants to return to the
> canonical version
> of the spec.)

SchemaLocation is a silly construct that simply adds complexity. Instead
of using the straight forward model of the namespace identifier this puts
similar information in another place messing up the model of what is a
document and what is an identifier.

> 3) I am using Navigator as my browser. It does not give me any
> indication what the resource at the other end of that link is when it
> fetches it, and does not display XML.  (My practise is not to follow
> every link in a document, especially if it involves saving
> the resource
> to disk and looking at it.)

You are willing to follow SchemaLocation but not NS URIs? This is like
saying that you are willing to follow URIs in IMG elements but not in
OBJECT elements in HTML - that doesn't make any sense.

> I agree with David.  The whole issue of versioning
> conventions is still
> up for grabs.

No it isn't. We have thought long and hard at the versioning model (or
extensibility in more general terms) in SOAP based on the experience from
HTTP and other places. The model really is pretty straight forward:

    * backwards compatible changes are done within the same NS
    * backwards incompatible changes are done in another NS

> If we coul use attributes for versioning, XML Schemas
> could probably deal with the issue; however, because in the WWW
> architecture it is natural that it goes as a URL issue, there is no
> natural body for defining versioning conventions.
>  An XML Schema does
> not even have a mechanism to express in itself what its URN or public
> identifier or canonical location should be (given that there
> can be many
> schemas for the same namespace.)

If you mean different representations then that is what you have HTTP
content negotiation for.

Henrik

Received on Wednesday, 20 September 2000 21:04:00 UTC