QA guidance on fragments

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

QA guidance on fragments

Jeremy Carroll

Concerning ACTION-89

The document I had in mind was:

I think the introductory text is well worth consideration

As a general principle, variability complicates interoperability. In
theory, interoperability is best when there are numerous identical,
complete, and correct implementations. However, when compared to the
alternatives, the net effect of conformance variability is not
necessarily negative in all cases. For example profiles — subdivisions
of the technology targeted at specific applications communities —
introduce variability among implementations. Some will implement Profile
ABC, some will implement Profile XYZ, and the two might not
intercommunicate well if ABC and XYZ are fairly different. However, if
ABC and XYZ are subsets of a large monolithic specification — too large
for many implementers to tackle in total -- and if they are well
targeted at actual application sectors, then subdivision by profiles may
actually enhance interoperability.

Different sorts of variability have different negative and positive
impacts. The principal danger is "excessive" variability - variability
that goes beyond what is needed for a positive interoperability
trade-off and that unnecessarily complicates the conformance model.
Specification editors need to carefully consider and justify any
variability allowed and its affect on conformance. This can be done by
referencing project requirements and use cases and/or explicitly
documenting the choices made.

The whole thing is fairly concise and worth a read in my view.

In terms of the discussion we were having yesterday, I think that if
there is substantial vendor interest in a particular fragment then that
should provide adequate positive impact to counter the negative impacts
- but that having too many fragments is likely to have the opposite effect.