Timelines for new standard and acceptance and deprecation of previous standard.

[tf-kosenenko]

We have recently run into an issue at Trace First where eCVIs have been sent to us that would have been valid against a previous XML standard but are not against the current standard (v2.4).

We have a proposal for timelines of adopting new standards and dropping support for old standards:

• 3 months after the release of a new XML standard: Vendors receiving eCVIs must offer support validating to the new standard.

• 6 months after the release of a new XML standard: Vendors sending eCVIs must no longer send eCVIs that would have been valid to the old standard but not to the new standard.

[SusanCulpDVM]

@ryanscholzdvm, who would be the entity who would set timeline enforcement standards? The National Assembly eCVI group?

[ryanscholzdvm]

@tf-kosenenko I think that timeline sounds like a good idea, but unfortunately, I don't think that there is really anything that this group could do to enforce it.

@SusanCulpDVM the NASAHO committee could include this in the approval standards at the next revision, but that would also only apply to the eCVI vendors. My guess is that the eCVI vendors are probably the more important ones to have a specified timeline for, but it does leave a potential hole with the database vendors.

Since there is a direct connection between the database vendors and SAHOs, there is probably less likely to be an issue with the database vendors keeping up with the standard.

With all of that said, we could include something into the standard to indicate an expected adoption timeline- we just wouldn't be the ones that could/would enforce it.

[jconlon]

For discussion of best practices for versioning. See: Semantic Versioning This best practice provides a kind of 'contract' between ecvi producers and consumers.

[mkm1879]

I believe we are all in agreement about semantic versioning. The only issue is the line between major and minor release. If we assume that an edit that requires either end to change anything is a major release, then we do nothing but major releases and should just have had 1, 2, 3, 4. The only changes we make that are truly backward compatible on both ends are documentation fixes. But the step from version 1.0 to 2.0 was a huge change while 2.3 to 2.4 was very small. I think there is value in reflecting the difference in our version numbers. Adding the generic movement root elements is another big change.

[jconlon]

The document XML Schema Versioning Use Cases provides a good discussion that is more specific for us when using XML Schemas.

From XML Schema Versioning Use Cases :

The term "backward compatiable" will mean that an instance document defined by an old schema can be processed by an application that handles the new schema.

The term "forward compatiable" will mean that an instance document defined by a new schema can be processed by an application that handles the old schema.

I think we can focus on the first idea of "backward compatiable', as we tend to be more processor focused so our consumers (processors validating instance documents) will always be the most current and expect at least current or older versioned instances generated by ecvi document producers.

As the XML Schema Versioning Use Cases](https://www.w3.org/XML/2005/xsd-versioning-use-cases/) draft shows there are ways to achieve a 'structural' backward compatibility when changing the schema and still validate instances that conform to a previous schema within a major release family. For example: Adding and optional element as a minor change to Schema N.(n).0 so a processor (consumer) using Schema at N.(n).0 validates instance documents still at N.(n-1).0 that don't contain the element.

Any changes where the producer does not need to be changed like documentations could then be considered minor changes.

[mmcgrath]

@jconlon and @mkm1879 would you mind moving the discussion on Semantic Versioning to another issue - it is nothing to do with the issue that @tf-kosenenko opened.

We have a current situation where we are receiving eCVIs from a provider that are invalid with respect to the current version of the standard. Unless the group agrees to publish some timelines for adoption of new versions and retirement of old versions, we are needlessly going to have a situation where providers can be "in conformance with the standard" but it is a old version.

[ryanscholzdvm]

86 was split off from this discussion and will be included in the new version that will be available after the USAHA meeting for implementation January 1. It doesn't really solve the issue the @tf-kosenenko was trying to get at, but hopefully will provide a stopgap to help with determining what version of the standard to validate against (although I suppose that requires the adoption of the new standard by the vendor). At the very least, databases should be able to determine that if an eCVI was created using the newest XML version as it should include that attribute.

I would propose that the actual timeline for implementation be considered a policy issue that gets taken up by the NASAHO eCVI committee. We will be meeting in early December to begin discussing updates to the NASAHO eCVI standards, and I think that a timeline for adoption will likely be included in those standards.