Re: Versioning and HTML

On Apr 27, 2009, at 7:27 AM, Norman Walsh wrote:

> Jonathan Rees <jar@creativecommons.org> writes:
>> So version indicators only support extensibility (or whatever other
>> goal you're after) if the future consequences for both old and new
>> consumers are articulated and documented before the whole process  
>> gets
>> started.
>
> But that's not uniquely true of version indicators, is it?

Agreed. I was just talking about version indicators in particular  
because
Larry seemed to give them special status.

> That's true
> no matter what technique is used to distinguish one version from
> another. The alternative, where there aren't any version identifiers,
> requires consumers to deal with both old and new markup as well.

agreed

> For some languages and some applications, it may be reasonable to
> define a universal semantics for all versions, such as the HTML rule
> of ignoring wrappers it doesn't recognize. (Not that that hasn't
> introduced problems of its own, with special elements created over
> time just to work around the consequences of the "ignore wrappers"
> rule.)

In case it wasn't clear I meant universal semantics *of the version
indicators*... which may imply constraints on the
interpretation of the rest of the input (including whether rejection
and acceptance are OK in any particular case).

> For other languages and other applications, it may not be reasoanble
> to define a universal semantics. Applications must be expected in that
> case to do something else. Version identifiers offer a convenient
> mechanism to help users distinguish between versions, even if machines
> don't need them: "Unexpected element 'fribble' encountered in this
> V1.2.3 document. The element 'fribble' is not defined in V1.2.3."

I think I'm construing "semantics" more broadly than you - I
mean it to apply to error reporting and other kinds of rejection
and remediation, not just to "correct" interpretation of "correct"
inputs. That is, to allow any particular input to be
flagged as an error is itself (what I would call) semantics. We're  
having so
much trouble with "error", "must accept", "must reject", "must  
understand", and
so on, that it ought to be useful to deconstruct a bit and just talk  
about the
desirability (payoffs) of these various outcomes for producer and  
consumer.
I expect it to be helpful to treat outcomes such as reject, ignore,
default, and understand uniformly, and talk about semantics (or  
specification)
not as giving the single "correct" outcome for all consumers
but as saying which possible outcomes are acceptable across
consumers of varying abilities and inclinations. So ask not "should
the consumer accept (or reject) X" but rather "should it be OK
with the producer if the consumer rejects (or accepts) X".

Best
Jonathan

>                                        Be seeing you,
>                                          norm
>
> -- 
> Norman Walsh <ndw@nwalsh.com> | Do not seek to follow in the footsteps
> http://nwalsh.com/            | of men of old; seek what they
>                              | sought.--Matsuo Basho

Received on Tuesday, 28 April 2009 14:38:16 UTC