Re: profiles, modules, levels [30, 41, 49, 50, 51, 97, 98]

Le dim 13/04/2003 à 02:07, Lofton Henderson a écrit :
> I have some sympathy with the idea that they could be combined.  But I 
> don't think it would be useful for us, on Monday, to simply endorse the 
> concept "combine them", without some clear idea of *how* to combine them.

I agree, this needs quite some work before we can discuss it
efficiently.

Some food for thoughts:
- our definitions of modules/profiles/levels are confusing, and I think
we're confused ourselves by them; the culprit here is the fact that we
re-use the labels of well-known divisions (CSS Modules, XHTML profiles,
DOM Levels), but with a slightly different intent; namely, we try to get
them design a much more symbolic notion than the one that was intended
behind their first usage, but I think we failed in making a clear
distinction between the concept we define and the reality they try to
describe. For instance, what is the real difference between a profile
and a level? It strikes me that profiles come from a top to bottom
approach when levels come from a bottom to top one, but I have no way to
say why a "level" in DOM could not be called a profile (same in CSS).
Maybe trying to think with other labels than profile/level would help us
make clear the abstract notions?
- I'm pretty sure our GL on levels is completely useless, because the
only checkpoint is about relations with other DoV, which could easily be
included in a combined GL
- the only of these 3 GL that affects conformance for "software"
implementations is the one about profiles, with CP 4.1 (mandatoriness of
a profile), 4.2 (minimal requirements for a given profile per class of
product). All the other CP in these GL are about the use of
levels/profiles/modules as a component of a specification, that is, how
someone can re-use the subset to create a new "specification" (in the
conformance requirements sense of the term).

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org