profiles/modules/levels -- 1 of 2

Next Monday is profiles/modules/levels day.  Here are some thoughts of 
mine, based on recent emails/minutes.

Pardon for verbosity.  Even splitting into two messages, it goes on.  But 
... I'm trying to be completely clear and unambiguous in the examples I'm 
citing here.

At 09:57 AM 4/18/03 +0200, Dominique Hazaël-Massieux wrote:
>Le ven 18/04/2003 à 02:16, Lofton Henderson a écrit :
> > At 09:46 AM 4/16/03 -0400, Mark Skall wrote:
> > >[...]
> > >DH: Profiles and levels are the same thing.
> > >
> > >LH: Disagree.  They are different but profiles can be levels.
> >
> > Oops, if that's what I said, then I mis-spoke.  It is backwards.  Should
> > be:  "Levels can be profiles.  Every levelled specification could be
> > written as profiles, but the converse is not true."
>
>FWIW, that's what I meant also by saying they are the same thing -
>namely, I don't think there is any benefit from distinguishing levels
>from profiles, since levels can easily be seen as profiles, and the only
>CP in the levels GL is one which is already present in the profiles GL.

I see profiles and levels as conceptually different.  Current definitions:

functional level
-----
"4. Definitions" -- a technology subset that is one of a hierarchy of 
nested subsets, ranging from minimal or core functionality to full or 
complete functionally.

profile
-----
"4. Definitions" -- a subset of a technology that is tailored to meet 
specific functional requirements of a particular application community. A 
profile may address a single technology; or, a profile can also group a set 
of technologies (i.e., from different specifications) and define how they 
operate together. Profiles may be based on hardware considerations 
associated with target product classes, or they may be driven by other 
functional requirements of their target communities.

As we have agreed, there is nothing in the definitions that *prohibits* 
levels from being called profiles instead.  (Btw, IMO we will *not* succeed 
in coming up with useful definitions that are tight enough to prohibit 
misuse of the concept.  More in next message, but briefly ... I think we 
can start to steer specifications towards a common, agreed usage of the 
concepts with a combination of definitions, discussion, and examples.)

But I think there are examples where calling a leveled technology 
"profiles" is awkward and inappropriate.  The best example (unfortunately) 
comes from outside of W3C -- the ISO CGM standard.  Taking some liberties 
with terminology, here is CGM and its evolution:

1987:  CGM level 1 published.
1989:  Level 2 added by addendum; CGM:1989 now defines levels 1 & 2.
1991:  Level 3 added by addendum: CGM:1991 now defines levels 1, 2, 3.
1994:  Level 4 added by addendum; CGM:1994 now defines levels 1-4.

The republished CGM:1999 defines 4 levels in the same document.  Each of 
these levels is a progressive functional enrichment of the previous one, 
*** targeted in aggregate at the sum of all principal CGM user 
constituencies' requirements ***.

Throughout the years, there have also been a number of CGM profiles.  The 
first (earliest) was a subset of CGM level 1, targeted at aerospace 
usage.  The most recent (WebCGM) is a subset of level 4, in a sense that 
needs to be carefully defined.  The subset actually cuts across each of the 
4 levels, but doesn't include *all* of any particular level.  It includes 
most (but not all) stuff from level 1, a lot (but not all) of additional 
stuff from level 2, a lot (but not all) of additional stuff from level 3, 
and most (but not all) of the additional stuff from level 4.

To me, it would be extremely awkward and unnatural to call the CGM levels 
instead "profiles".  Profile 1, 2, 3, 4?  I don't think so.  Profile 1987, 
1989, 1991, 1994?  Profile "full", "fuller", "fullest", 
"ultra-full"?  Facetious aside, the concepts don't match.  The fact that 
level 1 has several (subset) profiles defined makes it very awkward to 
redefine level 1 itself to as a profile (note:  there could be a "full" 
profile of level 1, just as there was the proper-subset MAP/TOP level-1 
profile in the 80's).

[Just to beat the CGM to death, one could also consider using 4 modules to 
define CGM:1999 -- the 1987 module; the 1989 module, defined as the l2-l1 
addendum; the 1991 module, defined as the l3-l2 addendum; the 1994 module, 
defined as the l4-l3 addendum.  However, these modules lack the "functional 
coherence" criterion that appears in the definition of modules (see my next 
message).  Each of the 4 "modules" in fact spans a wide breadth of 
functionality, targeted at diverse needs and purposes.]

Back to W3C standards.

DOM.  Level 1, level 2, level 3.  Here again is a historical development, 
and one is tempted to say "same as CGM" (but there is a subtle difference):

DOM1:1998 (2ndEd 2000)
DOM2:2000
DOM3:200x

Each level is a functional enrichment of the previous, like CGM.  Each 
previous level still exists as a valid W3C recommendation, however the DOM2 
specification does not normatively define the DOM1 subset (an 
implementation uses the 'hasFeature(feature, version)' to determine the 
level -- version=level).  By contrast, the specification for each level of 
CGM said "supersedes and replaces" the previous specification, and 
completely defined the whole set of levels (including rolling in errata, as 
W3C Editions do).

So the subtle difference.  CGM is a classical leveled technology, where all 
levels are defined in a single document.  DOM is effectively a leveled 
technology, but it is defined by a collection of 3 W3C Recommendations -- 
DOM1, DOM2, DOM3.  (Note.  I'm ignoring the DOM modularization for 
now.)  There is no single document that defines the 3 levels.  Therefore, 
levels in DOM fails our definition (LC-66) of a DoV.

Calling DOM1, 2, 3 as "profiles" instead of "levels" would to me seem 
awkward and inappropriate, in the same way and for the same reasons as CGM.

CSS is a similar case to DOM.  Calling CSS1, 2, 3 as "profiles" instead of 
"levels" would to me seem awkward and inappropriate, in the same way and 
for the same reasons as CGM.

SVG is an odd case.  I would consider the pending SVG 1.2 to be a "level 2" 
to the original SVG 1.0 "level 1".  Note that SVG1.1 modularized the 
functionality of 1.0, and defined 3 profiles:  full, basic, tiny.  Tiny is 
targeted at the cell phone hardware sector (diverse applications).  Basic 
is targeted at the PDA/handheld hardware sector (diverse 
applications).  Full is targeted at the desktop/workstation hardware sector 
(diverse applications).  IMO, it is muddy whether these are profiles or 
levels.  To me they seem more like levels, because one of their definition 
criteria is that each is a superset of the previous.  They do target 
hardware sectors (like profiles), but not specific application 
constituencies within those sectors (which profiles often do).

SpecGL.  A, AA, AAA could be considered classical levels.  Each subsumes 
and includes the previous.  Okay, you could also call 'em profiles.  But 
... where is the target application specificity that we imply for profiles?

Summary.  I think that levels and profiles are distinct concepts, although 
W3C doesn't have many (any?) clean, classical definitions of leveled 
technologies.

-Lofton.

p.s. Part 2 will follow soon.

Received on Tuesday, 22 April 2003 15:13:09 UTC