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

At 11:42 AM 1/14/2004 -0500, david_marston@us.ibm.com wrote:

>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.

QAWG was not willing to embed the dependencies normatively because:

1.) subtle, complex and difficult concepts;
2.) uncertainty whether the result of your dependency analysis is 
exclusively correct or always best (i.e., others' analyses might lead to 
different, but still logically consistent and useful dependency maps);
3.) normatively mandating how all DoV relate to all others would probably 
invalidate almost all existing practice within W3C.

Which is why we have a CP for each DoV, "define relationships to other DoV".

We are very weak on examples & techniques here.  IMO it would be nice to 
have a simple, tutorial-style explanation of your sequencing written up, in 
the style of Quick Tips, and attached to SpecET (or its pending CC 
templates).  Examples are needed as well.

The need for this is becoming clear, as we try to apply SpecGL to a 
complicated real situation.  (Perhaps an example will emerge from SVG12).

>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.

Yes, I definitely smell "techniques" here, in the form of a little QT 
document.  Although, before putting the work into it, we should take a 
quick reading of the stability of the CPs to which this would be attached.

>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.

My classical model of levels came from the ISO CGM standard.  Over 6-7 
years, CGM defined Version 1, Version 2, Version 3 (and then Version 
4).  Each defined the syntax and semantics of a progressively richer set of 
graphical elements.  Each is a superset of the previous.  They are Levels.

For example, in the realm of basic drawing primitives:  V1 (L1) defined 
elements for polylines, elliptical arcs, etc;  V2 added more complex 
entities like Closed Figure, that could assemble sequences of the V1 
primitives to draw complicated things with islands, holes, etc;  V3 added 
Bezier's and NURBS.

Is this what you mean by "higher levels of display capabilities"?  (The 
phrase sounds rather like levels of implementation of the viewer CoP, on a 
monolithic base of content/document functionality.)

(Btw, I believe that CoP is subservient to Levels in this instance, but 
that's another discussion.)

>Moving to Applications is a very drastic change in
>the entire flavor of what the end user would be doing.

I see where your thinking is going here.  But I'm not sure I agree.  It is 
possible to take a perspective where it is a matter of degree.  (Have a 
look again at the use cases of the Image subset and the Application subset 
in the SVG12 document.)  More below...


>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.

Not quite.  Image is strict, whereas static allows extensions.  Image 
allows declarative animation, whereas static does not.

Image is a graphics subset that is strict, and purely 
declarative.  Application admits extensibility, R/W DOM, scripting, a model 
for attaching rendering/processing handlers to arbitrary XML content, etc.

The power of the language increases, the range of objects that can be 
rendered (predefined vs. user defined), the dynamics and interactivity 
increase, ... It is in these senses that I have been thinking of it as 
"degree" -- in my view, it's all graphics, ultimately.

But it is an interesting notion to think of it as "different kind".  I need 
to ponder that some more.

>There would be some value in a discussion of the payoffs and pitfalls
>of multiple orthogonal sets of levels.
>.................David Marston

-Lofton.

Received on Tuesday, 27 January 2004 19:56:29 UTC