Re: CoP vs. Profile vs. ....

At 03:32 PM 1/13/04 -0500, you wrote:

> >SVG1.1 defines conformance for viewers...
> >a.)  Conforming Static SVG Viewers
> >b.)  Conforming Dynamic SVG Viewers
> >c.)  Conforming High-Quality Static SVG Viewer
> >d.)  Conforming High-Quality Dynamic SVG Viewer
> >So we have four kinds of viewers, generated by two orthogonal axes
> >(static/dynamic, and low/high quality).
>
>My instinct is that the above are all from the same Class of Product
>(CoP), because they are all viewers. In typical W3C usage, a viewer
>takes markup (HTML, XML) as input and produces human-detectable
>output on a suitable piece of hardware.

Fair enough.  Which of our 10 enumerated CoP would "graphic viewer" fit into?

If your answer is 3rd bullet,  "player (read-only consumer, conveys content 
in non- XML way)", then how do we reconcile the SVG-DOM API of Dynamic with 
"read-only"?

By the way, I don't think there's a single correct answer here.  But I'm 
looking for some application of our SpecGL principles which might provide a 
clear structure or framework for this question, plus the SVG11 
modularization, plus the Mobile profiles, plus yet another bifurcation that 
is under consideration:

http://www.w3.org/TR/SVG12/#imageapp
http://www.w3.org/TR/SVG12/#coreplus-theming

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

Themes almost certainly fit one or more of our three 
technology-partitioning methods (M/P/L).  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.

Perhaps some housekeeping could be done -- I'm not convinced that all of 
the dichotomies, on all of the axes, have strong use cases.  But if they do 
... it is a real challenge to sort it out:

-- There are the various CoP (document, generator, interpreter, viewer).

-- There are the SVG11 static/dynamic and plain/high quality bifurcations 
on viewers (resulting in 4 flavors of viewer).

-- There are the SVG11 modularization and the SVG11 Mobile use of those 
modules to define Tiny, Basic, Full profiles.

-- Each of those designations will have to be upgraded to accommodate the 
(significant) new functionality of SVG12.

-- And finally there is the proposed SVG12 "theming".

-Lofton.


>Looking around the rest of
>Appendix G reinforces my instinct, because the other sections
>address other CoPs (document, generator, etc.).
>
>I think the "plain" vs. "high-quality" is a classic example of
>levels, since one is a superset of the other. In a quick read,
>dynamic also seemed to be a superset of static, so those could be
>levels if necessary, but we have no clarity about orthogonal
>levels. Dynamic makes a nice add-on module, too. It could be a
>profile, but that implies a higher degree of separation from
>static. How's this look?
>
>Base (level 1) = Conforming Static SVG Viewer
>Base (level 2) = Conforming High-Quality Static SVG Viewer
>Base+Dynamic (level 1) = Conforming Dynamic SVG Viewer
>Base+Dynamic (level 2) = Conforming High-Quality Dynamic SVG Viewer
>
>So my quick answer is: Modules are good for static/dynamic, but
>profiles would also fit. Levels look good for high-quality,
>especially if advancing technology will later trigger "very high
>quality", "ultra high quality", etc. The CoP dimension is already
>spoken for in the range of conformance described in Appendix G.
>.................David Marston

Received on Tuesday, 13 January 2004 19:26:38 UTC