codelist — archive

[Anthony Coates]

We are simply chasing our tails here. If we are going to get to some resolution of this thread in finite time, we need to stop arguing at cross-purposes. In particular, we simply aren't agreeing from the outset as to what *conformance* is, and what the scope of it should be for the genericode specification. Although this is only marginally less vague a topic than many of the great philosophical questions of history (like what "love" is), we still need to get to a sufficient agreement on what the question is or we will never agree what the answer is. It's become clear to me that Ken and I have different views on how much of the "code list lifecycle" should be covered by the conformance. Ken's view seems to be (and forgive me for paraphrasing) that the important part of the lifecycle is the authoring of genericode documents, and that if those are valid and self-consistent, then anything that happens after that is somebody else's problem. By contrast, my view is that we need to be concerned not only with whether genericode documents are valid, but also whether applications process the genericode-specific parts of the information content in a consistent and repeatable way. Users are free to put all kinds of information in genericode documents, and interpret their own information as they like. However, the same code list (which may span multiple genericode files due to references) should not, in my opinion, appear to contain different information depending on which application opens it (excepting differences due to applications having different local copies of the same genericode file). For that reason, I believe that interpretation of the "structural semantics" (for want of a better expression) of genericode is an important and valid part of the scope of conformance, because it impacts directly on users perceptions and measurements of whether they get consistent behaviour from consuming applications or not. I also disagree with Ken's brief explanation of what conformance is (i.e. a short check list of the major points from the spec), and I don't think that is how OASIS would define it. I know the check list approach was mentioned as one possible interpretation, but I suspect that the inclusion of conformance as a separate issue for OASIS specs has been driven by Web services and the like, where it has not been uncommon see different implementations all adhering to the written specification, but via differing interpretations that are not interoperable. This kind of problem is no less important for genericode users. Anyway, how about we start with discussing how much of the "code list lifecycle" we can and should cover with conformance clauses? Once we agree on that, I think some of the answers will come more easily. By the way, part of the answer could be that we end up splitting the conformance clauses into "authoring" and "processing" sections, so that nobody feels duty bound to try and comply with conformance clauses that aren't relevant to the part of the lifecycle that they are responsible for. Cheers, Tony. On Tue, 04 Sep 2007 17:41:21 +0100, G. Ken Holman