- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 03 Jul 2002 10:25:25 -0600
- 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). >I >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 >circumstances. 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. Thanks, -Lofton.
Received on Wednesday, 3 July 2002 12:23:11 UTC