Re: profiles/modules/levels -- 1 of 2

At 06:30 AM 4/23/03 +0200, Dominique Hazaël-Massieux wrote:
>Le mar 22/04/2003 à 21:07, Lofton Henderson a écrit :
> > 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.
>
>I agree they are different. My point is that levels are a subclass of
>profiles, not that they are the same. Given our current definition of
>profiles though, I have to say it is more that profiles and levels are
>subclasses of a same concept (but I think we could generalize our
>definition of profile a bit for sake of simplicity).

I do not support "generalize definition of profile".  Reason:  As I recall 
(it's been a while), this definition is based on some fairly solid work 
about profiles from ISO (called "ISO TR 10000").  We didn't just invent the 
definition of profile.

Lynne, Mark -- is my recollection correct?

Second comment.  structurally, maybe levels could be considered special 
case of profiles -- hierarchically nested subsets are a special case of 
arbitrary subsets.  But part of what distinguishes profiles and levels is 
... intent and purpose (of the respective techniques for subdividing a 
technology).

Note.  I could use your argument to assert that levels are a special case 
of modules.  Example:  L3 contains L2 contains L1.  Therefore, I really 
have 3 modules:  M1=L1, M2=(L2-L1), M3=(L3-L1).  Structurally it 
works.  However, it really twists the notion of how people typically use 
modules (XHTML, SMIL, SVG, ...).  Then it becomes a complete nightmare, 
when one considers a technology like DOM (level 1, level 2, level 3) or CSS 
(level 1, level 2, level 3), which is also modularized!


> > 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. [...]
>
>All of this re-enforces my idea that we are confusing 2 issues: labeling
>and formalizing.

I think that we're asking for trouble if our formalization differs from our 
terminology, and from how the concepts are now being used in W3C and 
elsewhere.  (Perhaps I'm misunderstanding your point here.)

>I'm of course all for a consistent usage of
>denominations by the specifications, and I would not want to see the
>term profile used where the term level is currently used. But the fact
>that this different terminology is useful shouldn't hide the fact that
>levels are just one kind of profile!

However, IMO there is a difference in the purpose and aim.

>More specifically, I've nothing
>against the fact that SpecGL defines both profiles and levels, but I
>think we don't need to distinguish them in terms of DoV/GL, because we
>could fit any level-specific CP (which currently is only the cross-DoV
>CP) into the more generic profile GL/CP.

I'm skeptical.  But could maybe be convinced by a compelling proposal.

-Lofton.

Received on Wednesday, 23 April 2003 19:00:03 UTC