RE: Alternate syntax for required features.

Adding a new feature should only be necessary if we are adding a new feature to the spec or somehow dividing up the functionality of an existing feature, which would likely require a change to the schema anyway; and if we package the features up  into discrete modules, then such an addition should be self contained, much like we anticipate style extensions. Even if it does not, in my opinion the TTWG  changing the range of allowed or expected behavior of a processor is a large enough bar that the schema should change to reflect it; and indeed I oppose the current syntax on that grounds, that it is too easy to change in an undisciplined way.

 Third party changes only require definitions in their own namespace, and thus the schema would not have to change until a feature was well established in practice.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 16 April 2009 2:50 PM
To: Sean Hayes; Public TTWG List
Subject: Re: Alternate syntax for required features.



On 4/16/09 7:36 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
In either case the features work is a major part of the spec now, and should not be pushed off into an annexe, but should form a normative section in the main body.
It is normative as currently specified, so it matters not whether it is in an appendix or main body. I prefer an appendix, since it may be modified more frequently. In any case, I still oppose the proposed change, for no reason other than adding a new feature means adding a new attribute which means changing the schema. Any change to a schema should require a very high bar in my opinion.

G.