Re: CoP vs. Profile vs. .... (the saga continues)

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