[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AI 0028, summarize versioning questions re: assertions within protocol
On the 15-April call, my proposed text for the Versioning section in the core doc was accepted, but a new set of issues orthogonal to that text arose. I agreed to try and describe them. The central question is what to say about the version of an Assertion that can be carried in a particular version Response. Strictly speaking, responses mostly just carry assertions without any real interaction with the payload, so there don't appear to be any obvious issues from a profiling perspective. But, since the Response type is schema-defined to carry Assertion elements from a specific namespace, the interactions between the assertion namespace and the assertion version would currently affect what could be carried. Specifically, a 1.0/1.1 Response could not carry, perhaps, a 2.0 Assertion assuming the 2.0 assertion namespace is different. In my recently accepted text, I make clear that we expect namespaces to change or be introduced only during major revisions, but this is not a 100% certainty. We could however approach the problem from the namespace side, and simply say that the Response schema definition makes it evident that only Assertions of versions defined within the referenced assertion namespace can be carried. This would permit a 1.0 Response to carry a 1.1 Assertion or vice versa, but would make it explicit that a namespace change later would dictate whether the new assertions could be carried in that fashion. There doesn't seem to be any obvious reason to prevent the mixing of versions, since 1.1 implementations need do nothing to permit it, and 1.0 implementations already have to deal with a schema update for the ID attribute issue. In most minor revisions, we expect forward schema compatibility, so an old Response ought to be capable of handling a slightly newer assertion in future cases. Summing up, I see these options: a) Explicitly disallow mixing of versions to avoid potential complications that might arise in future work. b) Rely on the namespaces to dictate what can and can't happen, which implies that we allow mixing of 1.0/1.1 and may explicitly decide to permit 2.0 response to carry 1.1/1.0 assertions if we design the schema that way. c) Try and think through use cases (or a lack of) that might lead to processing rules like "newer responses can carry older assertions but not vice versa". d) ?? Your option here... -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]