W3C home > Mailing lists > Public > www-qa-wg@w3.org > July 2002

Re: DRAFT Minutes for 27-June-2002 Telcon

From: Lofton Henderson <lofton@rockynet.com>
Date: Wed, 03 Jul 2002 10:25:25 -0600
Message-Id: <>
To: skall@nist.gov
Cc: www-qa-wg@w3.org

At 11:33 PM 7/2/02 -0400, skall@nist.gov wrote:
> >
> > Do we have any clues yet, what was the intent behind this original
> > checkpoint 5.3?  I'm still trying to figure out what to do about it (or
>After leaving a message for Lynne and listening to her reply, it seems 
>that the
>question of mandatoriness for profiles came from CGM, where, apparently, 
>it was
>required that implementers use a specific profile (i.e, they did not 
>conform if
>they implemented the whole standard - they needed to implement a profile).

Aha, now I see (I was involved in that work).  There is a subtlety here, 
and it goes like this.  There is no concept of conformance to the full CGM 
standard itself -- outside of profiles, the word "conformance" has no 
meaning.  "Conformance" (content, generator, interpreter) is reserved for 
and applied to profiles.  The CGM standard itself contains one profile 
definition, called the Model Profile, which is *almost* the full standard 
(no extension allowed, some reasonable constraints and maxima, unambiguous 
semantics, etc).  You can conform to the Model Profile, but not to CGM 
itself -- for CGM itself, content can only be "syntactically correct".   Or 
you can conform to any other valid profile which is defined according to 
CGM's "Rules for Profiles" (a pro-forma for defining profiles is supplied 
in CGM).

>believe that, sometimes, this makes sense.

In CGM's case, it did.  In the original CGM standard, there were too many 
loopholes for interoperability to succeed -- no restriction on extensions 
and private data, lack of reasonable maxima and limits for some attributes 
and elements, vague or imprecise rendering semantics and criteria, 
etc.  This was fixed by the "Rules for Profiles" amendment (addendum), and 
reserving the concept of conformance to apply only in the context of a 
properly defined profile.

>There would have to be enough
>profiles defined where it would make sense to require that one of them get
>implemented.  I think it would also make sense to give the implementer the
>option of implementing a profile or not - it would depend on the

Whether or not it makes sense depends (as in the CGM case) on how well the 
base standard is written from an interoperability perspective.  If it is 
written well enough to support interoperability, then you don't need 
profiles.  But you still need clear conformance criteria, and these have to 
face an issue:  does the implementer have to do the whole standard, or can 
he/she do a subset?  "The whole standard" is sort of an ad-hoc profile in 
itself, isn't it?  If "subset", then I think you *must* define a few clear 
subsets if you expect any interoperability -- i.e., you can't just let 
implementers do whatever functions they want.  And then ... well, we're 
into profiles -- the subsets are profiles.

I can't think of any examples where it make sense to allow implementers to 
do whatever subset of the standard that they desire (at least, if any 
reasonable interoperability is expected.)  But then, my experience is 
limited.  Anyone think of examples?

>Thus, I think the checkpoint is valid, with some re-writing to
>clarify this intent.

I can do that now.

Received on Wednesday, 3 July 2002 12:23:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:28 UTC