[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [codelist] Re: Updated genericode specification
At 2007-09-05 13:15 +0100, Mason, Howard \(UK\) wrote: > From the perspective of our work on information exchange, >interoperability will require conformance testing that a document which >purports to comply with the specification is valid, and that an >application which purports to accept a genericode document as input >successfully interprets that document as intended - both reading the >syntax and interpreting the semantics. I agree these two are distinct ... especially given my desire to claim the files I publish are conformant (regardless of who uses them) and Tony's desire to claim applications using a genericode file are conformant. >You may also have a third case, >where you need to check that an application which purports to generate >genericode documents does in fact produce compliant syntax and >semantics. I think that is covered by the first of the two just by looking at the end result as being a conformant file. >-----Original Message----- >From: Anthony B. Coates (Miley Watts) [mailto:abcoates@mileywatts.com] >Sent: 05 September 2007 15:47 >To: Code List Representation TC >Subject: Re: [codelist] Re: Updated genericode specification >... >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. I didn't think we were. >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. I acknowledge this and as you state below, I don't see why we cannot have two sections in the conformance part of the spec: one for a properly formed file, and one for a properly acting program. >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). Right there is an issue that doesn't sit well with me and "application conformance", but I'll accept it if there is a separate section on file conformance. I've committed to the UBL TC to supply conformant genericode files and I don't think we need a running application to measure that. >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. But as you point out, they won't get consistent behaviour based on local files. >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. I totally agree. I don't think we are working at cross purposes at all. Mary, when an OASIS specification has a conformance clause, is it allowed to have sections whereby different subclauses are covered based on different perspectives of the same specification? . . . . . . . . . Ken -- Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1 World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Jul'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]