I think this is a good idea, worth considering now rather than later. It will end up saving work for providers, in the end, and will promote more responsive schema maintenance, because we'll be less afraid of breaking applications.
<br><br>
<div><span class="gmail_quote">On 7/30/06, <b class="gmail_sendername">Javier de la Torre</b> <<a href="mailto:jatorre@gmail.com">jatorre@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi again,<br><br>Sorry. I forgot something that might be interesting. If we want to<br>have the possibility to do Version number negotiation between clients
<br>and servers, OGC standards define a way to do it through the<br>getCapabilities operation.<br><br>Here is explained, taken directly from the WFS Implementation<br>specifications (replace OWS for TAPIR):<br><br>"An OWS Client may negotiate with a Service Instance to determine a
<br>mutually agreeable<br>specification version. Negotiation is performed using the<br>GetCapabilities operation [sec.<br>13] according to the following rules.<br><br>All Capabilities XML must include a protocol version number. In
<br>response to a<br>GetCapabilities request containing a version number, a web feature<br>service must either<br>respond with output that conforms to that version of the<br>specification, or negotiate a<br>mutually agreeable version if the requested version is not
<br>implemented on the server. If<br>no version number is specified in the request, the server must<br>respond with the highest<br>version it understands and label the response accordingly.<br>Version number negotiation occurs as follows:
<br><br>1. If the server implements the requested version number, the server<br>must send that<br>version.<br><br>2. If the client request is for an unknown version greater than the<br>lowest version that<br>the server understands, the server must send the highest version less
<br>than the<br>requested version.<br><br>3. If the client request is for a version lower than any of those<br>known to the server,<br>then the server must send the lowest version it knows.<br><br>4. If the client does not understand the new version number sent by
<br>the server, it<br>may either cease communicating with the server or send a new request<br>with a<br>new version number that the client does understand, but which is less<br>than that<br>sent by the server (if the server had responded with a lower version).
<br><br>5. If the server had responded with a higher version (because the<br>request was for a<br>version lower than any known to the server), and the client does not<br>understand<br>the proposed higher version, then the client may send a new request
<br>with a<br>version number higher than that sent by the server.<br><br>The process is repeated until a mutually understood version is<br>reached, or until the client<br>determines that it will not or cannot communicate with that
<br>particular server. "<br><br>Javi.<br><br><br><br>_______________________________________________<br>tdwg-tapir mailing list<br><a href="mailto:tdwg-tapir@lists.tdwg.org">tdwg-tapir@lists.tdwg.org</a><br><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-tapir">
http://lists.tdwg.org/mailman/listinfo/tdwg-tapir</a><br></blockquote></div><br>