Re: modularity in specifications

Thanks for the examples- it helps.  I'm not surprised that you didn't know 
exactly what I meant, since I'm trying to figure that out 
myself.  Basically, I'm tyring to figure out - from a QA perspective, in 
the Specification Guideline,

(1)  what does modularity mean for a specification  - (this is something 
someone mentioned in OASIS).  One interpretation is that in order to 
conform, several different pieces (modules) must be present and and those 
pieces must be conforming.  e.g., your SVG example and I'm thinking SMIL?
The question now is - is this something to address in the Spec 
Guideline?  If so, what Guideline/checkpoints make sense

(2) Maybe there isn't anything that needs to be said, other than #3.  Or is 
this something that Pubs Rules or Style Manual already requires - so we 
don't need to have it here?

 >#3  A specification is dependent on other specifications.  As part of the
 > conformance statements, should a checkpoint require that these other
 > specifications and their affect on claiming conformance of this
 > specification be described.

thanks
Lynne


3 AM 3/18/02, Daniel Dardailler wrote:

>I'm not sure I understand what you mean.
>
>Let's try to look at examples.
>
>If a player claims to support both SVG and CSS, can it be conformant
>to just SVG but not CSS ? or the opposite ?
>
>I think this depends on the spec itself. If the SVG specs mentions as
>part of its conformance claim that CSS must be supported, then the
>player has to go by it.
>
>By default, I think a given player can be conformant to just the
>pieces tested. Note that when there is a kind of layered dependencies,
>this may be impossible (e.g. you cannot claim conformance to CSS with
>your SVG player if you do not support all of SVG, since CSS is
>"applied" to SVG, but you could claim conformance to all of HTML in a
>duo SVG/HTML player where part of SVG fails).
>
>If your question along these lines ?
>
>Now, should the SVG spec add CSS to its conformance, is I think a
>question which depends on other parameters, more at the architectural
>level (it may not make sense that it doesn't for instance, or it may
>be required for accessibility, etc). So I don't think this should be a
>QA matter.
>
>What is a QA matter is that a description of conformance dependencies
>be present (your point 3 below).
>
> > 1.  An implementation is composed of several components.  In order for the
> > implementation to conform to the specification, all its components (the
> > implementation's components) must also conform to the specification.  So,
> > -- Conformance of the implementation is the same as the sum of all its
> > components, where each component conforms to the specification.  (Does 
> this
> > make sense for W3C specs?)  If what it means for a component to conform
> > (e.g., claim conformance) is described, would conformance of the
> > implementation also be specified?
> >
> > 2.  An implementation is composed of several components, where these
> > components conform to another specification.   So, if this can happen,
> > should we have a checkpoint that says that lists the specifications that
> > the components conform to?
> >
> > 3.  A specification is dependent on other specifications.  As part of the
> > conformance statements, should a checkpoint require that these other
> > specifications and their affect on claiming conformance of this
> > specification be described.  (Again does this make sense in W3C specs?)
> >
> > 4.  Any other cases of modularity and relationship between the modules 
> that
> > make up a spec?
> >
> > Thanks for the assistance.
> > lynne
> >
> >