- From: Lofton Henderson <lofton@rockynet.com>
- Date: Tue, 06 Aug 2002 13:16:08 -0600
- 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 UTC