On Wed, Jan 6, 2010 at 3:13 PM, Robin Berjon <[email protected]> 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
