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

Thanks for the feedback, Andrew.  More comments below...

At 07:02 PM 1/13/04 +0000, Andrew Thackrah wrote:


>Sounds like you have an abstract product class "Conforming SVG Viewer" and
>two concrete subclasses "Static" and "Dynamic".

For starters, I'd like to fit simple "SVG Static Viewer" into one of our 10 
enumerated CoP.  Recall that one of our CPs says, "use one of the standard 
CoP if it fits; if none fit, invent your own".   If something as common as 
a graphic viewer does not fit one of our standard items, then we have goofed!

Quoting from [3], "the most common CoP are:

     * content (of type, meaning, and format as defined in the specification),
     * producer of content (may be divided into initiators and modifiers),
     * player (read-only consumer, conveys content in non- XML way),
     * consumer in a one-way pipeline,
     * responding agent (e.g., server) of API (consumer and producer),
     * processor (consumer of its vocabulary/instructions),
     * module that hosts the processor,
     * producer of instructions/commands to processor,
     * profile derived from the specification's Rules for Profiles,
     * specification (guidelines). "

It seems to me that SVG Static Viewer might fit 3rd bullet.  SVG Dynamic 
Viewer (SVG-D-V) does not fit -- it includes SVG DOM -- hence it is not 
"read only" -- as well as such other dynamic functionality as declarative 
animation, scripting, event & hyperlinking support, etc.

I thought SVG-D-V might involve 5th bullet, although "agent" seems 
misleading if we're considering the whole SVG-D-V implementation.  The 5th 
bullet might apply to the DOM part of the SVG-D-V implementation.

>'"High-Quality" looks like it is
>a property of the (parent) class - so perhaps could be treated as a module 
>module comes nearest in our list to specifiying a 'flavour' of a class (I 
>think)

Whether "module comes nearest" is debatable.

That aside, I would like to avoid Modules for this, because there is more 
than I have revealed so far.  There is a modularization in REC SVG1.1 that 
defines functional modules -- basically each module corresponds to a 
chapter, which are divided along functional lines like Paths, Shapes, 
Filter Effects, Text, Animation, etc.  Some of the chapters are divided 
into two modules, Basic and Full, where Full includes all of Basic and then 
some.  Then, REC "SVG Mobile" uses the SVG1.1 modularization to define the 
profiles Tiny, Basic, and Full -- which are really like Levels, since each 
one is a superset of the previous one.

Confusing?

Anyway, back to Dynamic vs. Static and LowQ vs. HighQ.  Dynamic and Static 
correspond to distinct subsets of the normatively defined functionality of 
the SVG standard (specific SVG elements, SVG DOM methods, etc), and to 
different content that must be supported in SVG files.

LowQ vs. HighQ is mostly about some enhanced rendering requirements for the 
functional content of given SVG files.

I am also thinking about whether CP8.2 [4],

" If special conformance concepts are used, include a definition in the 
specification."

or CP8.5 [5],

"Identify and define all conformance designations."

might have a role here.  (And btw, how does CP8.5 relate to the Seven 
Deadly Sins -- the seven DoV?)

-Lofton.

[3] http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/concepts#spec-cat-cop
[4] 
http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/guidelines-chapter#Ck-define-policy
[5] 
http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/guidelines-chapter#Ck-define-all-levels


>On 2004.01.13 18:40 Lofton Henderson wrote:
>>David (& everyone) --
>>As input to its current f2f meeting, I'm trying to make a contribution to 
>>SVG to help sort out (for SVG1.2) a messy situation involving lots of 
>>DoV.  I have a question that I'd like your feedback on (by CoB today, if 
>>possible).
>>SVG1.1 defines conformance for viewers [1], in some "sub-categories":
>>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 initial thought was to designate these as 4 classes of product 
>>(CoP).  The seem to fit SpecGL's generic definition of CoP at [2].  Then 
>>I try to classify them according to our enumeration at [3].  Problem:  I 
>>don't understand the brief abstract definitions at [3] well enough apply 
>>them to a-d above.  (Recommendation:  we *really* need a lot of stuff in 
>>SpecET, or else a Quick Tips linked from SpecET, that disambiguates and 
>>helps people apply this concept.)
>>Can you suggest a classification of a-d according to [3]?  E.g., #a--3rd 
>>bullet, #b--5th bullet, etc.
>>Although all 4 seemed to me to be CoP (at least the way they're treated 
>>in the Conformance Clause [1]), it then occurred to me:  maybe #a & #c 
>>are two profiles (or levels?) of the same CoP (SVG static viewer), and #b 
>>& #d are two profiles of another CoP (SVG dynamic viewer).
>>Then it occurred to me:  maybe all #a, #b, #c, #d are 4 profiles of a 
>>single CoP (SVG viewer).
>>There are lots of ways to parse it!  (And ... it is not a trivial task to 
>>apply SpecGL/ET to a complex conformance problem!)
>>What do you think?
>>-Lofton.
>>p.s.  I singled out David because he drafted a lot of the CoP stuff.
>>But I'd be happy to hear from anyone/everyone.
>>[1] http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
>>[2] 
>>http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/definitions#definitions
>>[3] http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/concepts#spec-cat-cop
>

Received on Tuesday, 13 January 2004 16:40:14 UTC