CR for Schema Location URLS as described in 06-135r5 r6
OGC Doc 09-024
Open Geospatial Consortium
CR-Form-v3
CHANGE REQUEST
Policies CR ?09-024
Related to
OGC
Standards
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
Title:
Schema file location URLs should include all version number components.
Source:
CubeWerx Inc (Keith Pomakis)
Work item code:
Category:
Other
Date: 2009-MAR-09
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:
However, since bug fix revisions use the same namespace within
a minor version, in order to discourage the use of superseded
versions, bug fix versions prior to the most recent one ought not
to be available for online validation.
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.
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.
Last Revision Date: 2 December 2017
Page2
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:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
13.5
X Other core specifications
X Abstract specifications
Best Practices Document
All of them!
All of them!
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?
NEW
How to create CRs using this form:
Last Revision Date: 2 December 2017
Page3
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.
Last Revision Date: 2 December 2017
Page4
Open Geospatial Consortium
CR-Form-v3
CHANGE REQUEST
Policies CR ?09-024
Related to
OGC
Standards
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
Title:
Schema file location URLs should include all version number components.
Source:
CubeWerx Inc (Keith Pomakis)
Work item code:
Category:
Other
Date: 2009-MAR-09
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:
However, since bug fix revisions use the same namespace within
a minor version, in order to discourage the use of superseded
versions, bug fix versions prior to the most recent one ought not
to be available for online validation.
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.
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.
Last Revision Date: 2 December 2017
Page2
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:
Other specs
Affected:
Supporting Doc.
Other comments:
Status
Disposition
13.5
X Other core specifications
X Abstract specifications
Best Practices Document
All of them!
All of them!
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?
NEW
How to create CRs using this form:
Last Revision Date: 2 December 2017
Page3
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.
Last Revision Date: 2 December 2017
Page4