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 10:39:38 UTC