[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [codelist] Re: Updated genericode specification
Hi Ken, I think what you're asking about are profiles? That is, if you're using this spec to accomplish 'a', then you must conform to 1-3, 4-6 are optional, and 7-10 are excluded. Or that 1-5 are base requirements, and then depending on profile a, b, c, or d, the additional requirements change. That is perfectly acceptable (and oftentimes encouraged), and fairly well-defined in the prior work done by the Conformance TC a few years ago. The pointer to that document is: http://www.oasis-open.org/apps/org/workgroup/ioc/download.php/305/conformanc e_requirements-v1.pdf If you were asking something different I'll be happy to try again ;-) Regards, Mary > -----Original Message----- > From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] > Sent: Saturday, September 08, 2007 1:51 PM > To: Code List Representation TC > 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]