- From: <david_marston@us.ibm.com>
- Date: Wed, 14 Jan 2004 11:42:36 -0500
- To: www-qa-wg@w3.org
Some of you may recall that about 1.5 years ago, I arranged the DoV (Dimensions of Variability) in a particular sequence. This was after a period of deep thought in which I matrixed all the DoV against each other, attempting to decide which direction of dependency was most natural. For example, between levels and extensions, the levels are the independent DoV and the extensions are dependent, because the need for, or capability of, the extensions can best be decided by the implementer after they decide which level to implement. A higher level may make some extensions unnecessary. One result of that analysis was that Class-of-Product (CoP) should be the most independent of all. The implementer, whose products will be subject to conformance testing, may decide to produce only some of the products defined in a multi-CoP spec like SVG. After that decision follow the dependent decisions about which modules, levels, etc. for each product. It makes sense to organize the specs that way as well. When the WG wants to products to mesh, such as a producer and consumer, they may sometimes make the profiles or levels match up, but none of the DoV is likely to spawn a choice that drives the WG to define a CoP that they weren't already contemplating independently. The benefit of this arrangement of the DoV into a dependency sequence will now be evident in the SVG example. Abstractly, deciding the DoV in order of dependency simplifies the problem of thinking through the many dimensions, and it also opens opportunities for flexibility. With that background, you can better understand my responses to Lofton's later missives. DM>>I think the "plain" vs. "high-quality" is a classic example of DM>>levels, since one is a superset of the other. >Except of the four CoP -- document (content), generator, interpreter, >viewer -- it pertains almost exclusively to viewer. Since SVG revolves >around the content definition (the language), it is counter-intuitive to >me to call these "levels", as they affect only 1/4 CoP. The above rationale explains my answer. The level DoV follows (is dependent on) the CoP DoV. One CoP needs these levels, and the others don't. >Which of our 10 enumerated CoP would "graphic viewer" fit into? It's a "player" (third bullet) if it's read-only. An editor or similar interactive tool is a combination of two products, or maybe three. The part that previews the rendered SVG is the player component. It may consume SVG to produce different SVG as well. (Remember that CLASS of Product does not have to be a real-world type of software tool. In particular, most producers probably have bits of other CoPs in their real-world implementations.) >"Themes"? Well, they have conformance criteria attached. The two >themes are "image" and "application". Image is a somewhat-static >graphics subset of all of SVG12 (but allows declarative animation), >with strict conformance attached -- no extensions, plus presumably no >optionality, discretion, etc. Application is the full language, >including extensibility, DCC (super-extensibility!), optionality, DOM, >scripting, etc. Based on a quick read, I see that as a meta-CoP planning device. The next step is: If I'm doing Images, what CoPs will I use? If I'm doing Applications, what CoPs will I use? >Personally, I like Levels. Level 1 (image) is the basic, pure, >strict-conformance graphics level. Level 2 adds to that all sorts of >stuff that turns it into a graphics application development language. Interesting. I think this pushes the idea of "levels" much further than previous dicussions. I think we have been talking all along about higher levels meaning higher display capabilities, fuller sets of features, etc. Moving to Applications is a very drastic change in the entire flavor of what the end user would be doing. I think it's also fair to note that we have other uses for levels in partioning SVG, so we should guide the WG to pick the variability that most resembles a difference of degree rather than kind, and apply the division by levels there. BTW, is this "theme" dichotomy just a more advanced or broader version of the static/dynamic dichotomy? It appears that static is entirely within the Images theme. There would be some value in a discussion of the payoffs and pitfalls of multiple orthogonal sets of levels. .................David Marston
Received on Wednesday, 14 January 2004 11:43:35 UTC