W3C home > Mailing lists > Public > www-qa-wg@w3.org > July 2004

Re: [SpecGL Draft] D1 Subdivide the technology

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Thu, 22 Jul 2004 09:19:35 -0400
Message-Id: <5.1.0.14.2.20040722091426.00b007d8@mailserver.nist.gov>
To: Karl Dubost <karl@w3.org>
Cc: www-qa-wg@w3.org


>
>Le 20 juil. 2004, à 14:43, Lynne Rosenthal a écrit :
>>  This seemed to get too long, but its always easier to cut out words.... 
>> This is the first Good Practice, which if you don't do, then you skip 
>> over the rest of the Principles and Good Practices. These subsequent 
>> Principles and GP will be sent later (I still have to write them).
>
>A kind of dependencies? :)

Yes.  Conditional Principles/GP


>>  Comments?
>>
>>D1 Subdivide
>>  Subdividing the technology should be done carefully  it is not always a 
>> good idea.  Be smart when dividing the technology so that it is not 
>> excessive and provides a positive impact on implementation and 
>> interoperability.  Too many divisions complicates conformance and can 
>> hinder interoperability by increasing the chances of conflict with other 
>> aspects of the specification (e.g., other subdivisions).  Requirements 
>> may be in multiple places and/or duplicative, making them more difficult 
>> to find and increasing the probability of conflict and 
>> misinterpretation.  Subdividing the technology increases the likelihood 
>> that implementations will implement different subdivisions and thus not 
>> interoperate
>
>The first thought which comes to my mind is what some persons will reply. 
>Something on the line:
>         "Yes, but subdividing a Spec which will not be a big fat cat and 
> that nobody will even try to implement at all. Example, look at the SVG 
> 1.0 Specification... etc."
>So I would say something that will show the costs and the benefits.:
>
>"""
>Same introduction
>
>* Costs:
>         Too many divisions complicates conformance and can hinder 
> interoperability by increasing the chances of conflict with other aspects 
> of the specification (e.g., other subdivisions).  Requirements may be in 
> multiple places and/or duplicative, making them more difficult to find 
> and increasing the probability of conflict and 
> misinterpretation.  Subdividing the technology increases the likelihood 
> that implementations will implement different subdivisions and thus not 
> interoperate
>
>* Benefits
>         Subdividing the technology in small units will be easier to 
> implement individually. It will help to organize the structure of the 
> technology.
>"""

I had a similar idea.  I was trying to create a table with subdivided 
standards vs monolithic, single standard, but couldn't put it together. 
This (costs/benefits) is a better way to start.

>Though I guess the GPs are about the benefits but in the intro, it might 
>be good to have as small reminder.
>
>>  Good Practice: Subdivide the technology to foster implementation
>>
>>
>>  Examples:
>>  Modules: example?
>
>         XHTML Modularization and SMIL gives good examples.

Good.

--Lynne
Received on Thursday, 22 July 2004 09:22:38 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:16 GMT