Open Geospatial Consortium
OGC Doc 09-024
CR-Form-v3
CHANGE REQUEST
Policies
Related to
OGC
Standards
CR ?09-024
rev-
Current version: 06-135r6 For
HELP
on using this form, see bottom of this page or look at the pop-up text over the symbols.
Proposed change affects: AS Imp Spec Best Practices Paper X Other
Title: Schema file location URLs should include all version number components.
Source: CubeWerx Inc (Keith Pomakis)
Work item code: Date: 2009-MAR-09
Category: F
Use one of the following categories:
F (Critical correction)
A (corresponds to a correction in an earlier release)
B (Addition of feature),
C (Functional modification of feature)
D (Editorial modification)
Detailed explanations of the above categories can be found in the TC Policies and Procedures.
Reason for change: Current proposal of using a 2-digit version number (X.Y) in URLs for locating schemas is not interoperable if we assume that corrigenda can introduce syntactic or semantic corrections/changes.
Summary of change: Use all version number components in URLs to locate schema files. Since OGC currently uses a 3-segment version number then all three segments should be used.
Consequences if
not approved: Section 13.5 of OGC 06-135r6 states that the official locations (URLs)
of the schema documents of a particular version of a specification should include only the x.y components of the version number, and that the documents residing at these URLs should be replaced with the latest x.y.z schemas as each corregendum is introduced. It even goes on to state:
The OGC Technical Committee Policies & Procedures 05-020r3
This is a departure from the tried-and-true OGC practice of giving each x.y.z schema its own location (and made available for online validation), and I believe it will have major negative ramifications if it's adopted as the new practice. It makes the highly unreasonable assumption that all deployed client and server software can immediately be updated the moment a new corregendum is released. This doesn't happen in practice, and will never happen regardless as to how strongly the use of superseded versions is discouraged.
The result would be a base of deployed software whose XML documents are compliant to the schemas for version x.y.z of the specification (the version that the software was specifically coded to), but
whose schema references are to the schemas for version x.y.<latest> of the specification. If there are any syntactic differences in the two versions, then the XML documents will fail to validate. If the software uses an XML parser which performs automatic validation (and many do), the software will fail. Stated in clearer terms, the moment a new schema version x.y.z+1 is introduced, it will immediately break a significant fraction of deployed client and server software, as well as any other services that happen to be in the same service chain as these services. Even if the OGC policy requires that non-validating parsers be used (which it doesn't, and most definitely shouldn't do), this is still an issue. An XML document is not valid if it refers to a schema document that it cannot validate against, regardless of whether or not such validation is attempted.
It has also been suggested (outside of 06-123r6 but stated as an implication of these proposed changes) that the version-negotiation mechanism be similarly altered to use only x.y version numbers.
This change would be even more disastrous! There would be no way for a client and a server to negotiate the specific version(s) (including
corregendum) for which they have been designed. A client may have been written in compliance with version 1.2.0 of a specification, but would be unable to indicate that to the server because it would only be able to say "1.2". The server might therefore respond with a version-1.2.1 capabilities document. (In fact, according to the proposed rules, a server would be REQUIRED to respond with the latest 1.2.x version in order for the XML document to be valid according to the schema it references. And of course that would be impossible to achieve in general unless all server software is updated and redeployed the instant a new corregendum is released.) The client would then have only two choices.
The OGC Technical Committee Policies & Procedures 05-020r3
It could give up and say that version negotiation has failed (which would be a shame because the server might otherwise have been able to negotiate to version 1.2.0 if the specification didn't forbid it), or it could continue to communicate with 1.2.0 semantics and syntax, pretending that it's 1.2.1 and hoping that the differences between the two versions are small enough not to cause problems. In other words, everything would be back to guesswork and finger-crossing. That's not version negotiation.
In response to this objection, a more complex version-negotiation mechanism has been suggested whereby clients can continue to request x.y.z version numbers but are encouraged to use x.y instead. However, this doesn't actually solve anything. Encouraging clients to request x.y is encouraging all of the problems stated above. And even if the client requests a specific x.y.z, the XML document it gets back may still not be validatable against its schema. All this complex version-negotiation mechanism does is complicate version negotiation, making it less likely to be implemented correctly. Either way (using this more complex version-negotiation mechanism or simply forcing x.y only), version negotiation would be incompatible with older (i.e., all existing) servers, that were never equipped to handle version-negotiation requests for x.y versions. Older (i.e., all existing) servers have a
right (and, some would even argue, a requirement) to reject the value of an AcceptVersions parameter, and thus the entire GetCapabilities request, if it contains an x.y version number.
Clauses affected: 13.5
Other specs X Other core specifications All of them! Affected: X Abstract specifications All of them!
Best Practices Document Supporting Doc.
Other comments: In light of all this, the question really needs to be asked: Why exactly are these changes in practice being made? What exactly is the problem that this new approach is attempting to solve?
In summary, if a corregendum is able to make any changes to either the semantics or the syntax of any of the messages that a service can send or receive, then it is critical that x.y.z version numbers be continued to
be used everywhere (with the possible exception of the schema namespaces, where x.y is probably harmless enough). And if a corregendum is unable to make such changes, then, well, what exactly can a corrigendum do? Status NEW
Disposition
How to create CRs using this form:
The OGC Technical Committee Policies & Procedures 05-020r3 Comprehensive
information and tips about how to create CRs can be found at:
https://portal.open geospatial.org/files /?
artifact_id=10678. Below is a brief summary:
Fill out the above form. The symbols above marked
contain pop-up help information about the field that they are closest to.
Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word "revision marks" feature (also known as "track changes") when making the changes. All Open GIS specifications can be downloaded from the OGC server under
http://www.opengeospa tial.org/specs/
If a Word version of the document is not available, please contact the TCC or his designee.
With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of the clause containing the first piece of changed text. Delete those parts of the specification that are not relevant to the change request.
