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

Re: Modules and levels in a specification

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 06 Aug 2002 13:16:08 -0600
Message-Id: <5.1.0.14.2.20020806110615.02c0cdb0@rockynet.com>
To: Andrew Thackrah <andrew@opengroup.org>
Cc: www-qa-wg@w3.org

At 11:52 AM 8/6/02 -0400, you wrote:
>[...]
>  re SpecGL modules/levels/profiles
>
>  I'm not clear on the difference between a level and a spec version - are
>  they different?

I think they are different in principle, but they can be the same in 
practice.  For example, I wouldn't consider CSS2.1 to be a level distinct 
from CSS2.  Its title is:  "Cascading Style Sheets, level 2 revision 
1".  The chapter "CSS 2.1 vs CSS 2" characterizes the differences as 
interoperability adjustments, error corrections, etc.  But CSS2 and CSS3 
are levels -- major functional increments.  DOM level 1 and 2 are both 
levels and versions (correct this if it is wrong, but I don't think there 
were any intervening versions, e.g., DOM 1.x).


>  Also I currently regard profiles to be a form of product categorization
>  rather than an aid to technical specification.

I would agree that the goal of profiling is not primarily to aid "technical 
specification".  We repeat these words at the start of each of GL3, GL5, 
GL7:  "Dividing a specification into functional groupings can facilitate 
its implementation by enabling a developer to build to portions of the 
specification rather than implementing the entire specification."

The definition of profiles (in the body of the text, I have also added it 
to the "Definitions" section for the next version):  "a subset of a 
specification or set of specifications that is tailored to meet specific 
functional requirements of a particular application community."

So yes, profiles are about applications (or application sectors).  The 
driving motivation is to improve interoperability of products.


>  For example when I see products claiming conformance to a technology it
>  is either with reference to a particular specification (e.g. 'conforms 
> to HTTP 1.1')
>  or to a product  brand (e.g. 'UNIX') which is a collection of 
> conformance requirements
>based on a number of lower level specs.
>
>  In the first case, HTTP 1.1 we have a named spec and a quoted version. The
>  version is very important here. If HTTP had been designed post-specGL would
>  we be saying 'conforms to HTTP level 3' instead?

Maybe.  Forgive my ignorance of HTTP, but does 1.1 contain a substantial 
chunk of additional functionality on top of 1.0?

I remember one comment from our first face-to-face, and it was about this 
very thing:  all of our specs have chosen different methods and labels to 
talk about the same things.


>  In the second case, if a profile is used to group modules under a name - 
> is this
>not a form of product classification?

In the sense that we are using "product class" in GL2, I would say 
"no".  Profiles codify the requirements, for multiple classes of product, 
for specific application sectors.  Example:  SVG Tiny (typical: mobile 
phone), SVG Basic (typical:  PDA), SVG Full (typical: desktop 
workstation).  And all sorts of products are addressed:  documents, 
authoring tools, transcoders, viewers, editors, etc.

>I am wondering why a technical specification
>author should be concerned with issues of product development such as
>profiling.

SVG 1.0 didn't worry about it -- we just invented a massive pile of 
graphical functionality.  It is my opinion that interoperability of 1.0 
will forever be problematic, as there was way too much functionality for 
any given community, no one will implement it all (no one has yet, and I 
think a "complete" implementation may be far in the future), and the 
industry will not agree spontaneously on more manageable subsets.

SVG1.1 modularized, and SVG Mobile defined the three profiles.  Virtually 
all of the WGs work for the last year (after 1.0) was driven by the 
requirement that SVG 1.0 needed to be profiled for these small mobile 
devices, in order for there to be any successful uptake in those 
sectors.  Those requirements were written into the WG re-charter.

>Perhaps the division of a specification by module is sufficient for a
>technical description. Any structuring or aggregation of modules and 
>discretionary
>elements can be performed as needed by product vendors and in conformance
>programs.

I would agree that a properly structured standard can be profiled by 
others, outside of the technical WG.  This is the whole thrust of the 
design of XHTML and SMIL (and SVG).  They have each defined a profiling 
framework, and each have also defined a small number of profiles that 
satisfy their WG's chartered requirements and use cases.

But the technical WG can also write the profiles, if the (chartered) 
requirements and use cases indicate that it is appropriate.


>We discussed last week if there were any examples of specs that started life
>with a clear product development plan (using levels) and had trouble 
>thinking of
>many. This may be because authors of technical specs are more concerned
>with capturing the functionality than speculating on future developments. 
>There
>may be good arguments for spec authors to think ahead to the further 
>development
>of their technology but can this not be addressed by versioning?
>
>Also is there not a danger that product classification (if that what 
>profiles are) is treading
>on the toes of vendors and maybe even inhibiting creativity in the area of 
>product
>devlopment?

No and yes...

No:  if the standards are written well, then you ought to be able to write 
a profile that encompasses the needs of any significant application 
community (e.g., some people are already talking about a SVG "Pico" 
profile, for processors in counter-top appliances.)

Yes:  it does discourage the implementation of random sets of 
functionality.  In my experience (esp graphics standards), that has caused 
some complete interoperability melt-downs, real disasters and failures of 
some standards in the field.  (To the point where I think the technical 
details of the standard are almost secondary:  an average standard with 
excellent interoperability framework is much more likely to succeed than a 
brilliant standard with poor conformance framework).

In the end, profiles are an optional tool for spec writers -- one of 
several.  Profiling has had heavy uptake for a long time now (ISO, W3C, 
others, ...)  Obviously it is not for every standard.  In the end, also, 
product builders choose whether or not to align with profiles -- some will, 
some won't.

-Lofton.
Received on Tuesday, 6 August 2002 16:01:14 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:10 GMT