RE: [codelist] Re: Updated genericode specification

["Mary McRae" <mary.mcrae@oasis-open.org>]

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