- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 6 Jan 2010 20:47:22 +0100
- To: Robin Berjon <robin@berjon.com>
- Cc: "cyril.concolato" <cyril.concolato@telecom-paristech.fr>, public-webapps <public-webapps@w3.org>
On Wed, Jan 6, 2010 at 3:13 PM, Robin Berjon <robin@berjon.com> wrote: > On Jan 6, 2010, at 11:08 , Cyril Concolato wrote: >> There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: >> >> <widget> >> <name>d4</name> >> <feature name="invalid feature IRI" required="true"/> >> </widget> >> >> I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. > > The ignore-unknowns strategy is largely built in order to support extensibility: because you ignore stuff you don't understand, it's possible for a v1 processor to process a v27 document (assuming it's designed to be compatible, which it should if it's using the same namespace). > > In the case of feature names however we already have all the extensibility that we ought to need: IRIs are completely open. Consequently I can't think of a situation in which an author would produce an invalid feature name on purpose, so this is an obvious error. > So you support leaving the spec as is, right? -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 6 January 2010 19:47:49 UTC