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

Ian Hickson wrote:
>> 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.

Yes. So what?

If this WG (the HTML WG as of 2008) defines the syntax for future 
elements to be non-void, and code implements that behavior, I'd be 
surprised if a future WG would reverse that decision.

>>> 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.


> ...
>>>> 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?

That was the initial question; I was asking about the specific xml:space 

And no, I do not agree that specifications need do that in all cases, or 
that that handling needs to be the same in all contexts.

>> 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.)

That's a very verbose way to state "must ignore unknown values".

So, if XML 1.0 *did* say that, how would you then introduce a new value? 
Older recipients would ignore it, after all.

Best regards, Julian

Received on Tuesday, 30 December 2008 13:31:53 UTC