Re: ZIP-based packages and URI references into them ODF proposal

On Tue, 30 Dec 2008, Julian Reschke wrote:
> > >
> > > So why doesn't HTML5 fix this, for instance by stating that the void 
> > > elements are exactly those defined in HTML4, and every future 
> > > element will be non-void?
> > 
> > What you describe isn't a fix, it's a statement of intent. It makes no 
> > sense really for a specification to say what future working groups 
> > will do, because we don't know.
> 
> Of course it makes sense for a specification to state how extensibility 
> works.

Stating what the extensibility mechanisms of a language are, and stating 
the future actions of as yet non-existent working groups, are two very 
different things.


> > > > The key part is "the XML processor MAY report the error or MAY 
> > > > recover by ignoring the attribute specification or by reporting 
> > > > the (erroneous) value to the application". This is the three 
> > > > options I gave above -- report an error, ignore the error, or 
> > > > report the value to the next level and let it deal with it however 
> > > > it wants, i.e. interpret and "correct" it. That isn't going to 
> > > > lead to interoperability. Some UAs will have fatal error handling, 
> > > > some will ignore it, some will "correct" it and treat it as 
> > > > 'preserve', some as 'default', some maybe as yet something else -- 
> > > > and all
> > >
> > > ..."correcting" it would be a bug, as far as I can tell...
> > 
> > Why? What requirements would it violate? The XML spec doesn't seem to 
> > constrain applications from doing whatever they want with the values 
> > they are passed, including the values of xml:space.
> 
> OK, so what exactly do you understand by "correcting"?

A user agent is correcting an error if there exists two or more values 
both of which are non-conforming for which the user agent's behavior is 
different. In other words, if it doesn't treat all incorrect values the 
same.

For example, in HTML, the de-facto handing for color values defines a 
mapping for any string to an RGB value, such that different invalid values 
have different resulting RGB values. On the other hand, the CSS handling 
for color values treats all invalid color values in the same way -- they 
all get ignored.


> > > The outcome of this definition in any case is that no new values for 
> > > xml:space can be introduced -- whether that was the intention, I 
> > > don't know.
> > 
> > The outcome is exactly the outcome I described for the case where 
> > there is no definition, which makes sense since there is indeed no 
> > defintion here. It's just one more example of why specs should define 
> > processing requirements in detail, for all inputs, for all conformance 
> > classes.
> 
> At this point I'm not sure whether we're disagreeing or not.

Do you agree that specifications should define handling for all inputs and 
all conformance classes in detail and unambiguously? Or do you think that 
specifications should define an abstract language with its abstract 
meaning, and not define the nitty gritty of implementation details?


> If the intent was to allow future extensibility for xml:space, this was 
> a failure. On the other hand, if the intent was to allow exactly those 
> two values, then the spec is fine the way it is.
> 
> So, assuming we *did* want extensibility here -- how would *you* define 
> it?

I would have said something along the lines of:

   "If the xml:space attribute is present and its value is the 
   case-sensitive value "preserve" then the element is in the "preserve 
   spaces" state; if the xml:space attribute is present and its value is 
   the case-sensitive value "default" then the element is in the 
   "default spaces" state; otherwise, the element is in the same state as
   its parent element, if there is one, or the "default spaces" state 
   otherwise.

   When an element is in the "preserve spaces" state, the user agent 
   must...

   Otherwise, the element is in the "default spaces" state, and the user 
   agent must..."

(I'm not sure exactly what the two states are supposed to do, as the XML 
spec actually fails to define that too. But whatever they are supposed to 
do, should be filled in above in the appropriate places.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 30 December 2008 12:51:43 UTC