Re: edition incompatibilities and consequences (formerly: Proposal: Fix discrete to animation in SVG 1.1 Second Edition)

Cameron McCormack:
> Dr. Olaf Hoffmann:
> > Are there already ideas how to indicate an SVG 1.1 second edition
> > document, for example version="1.1.2" or something like this?
>
> No, there won’t be a new value for that attribute.
>
> > This becomes more and more important, if the number of incompatible
> > changes of definitions in the second edition increases even more ...
> > Else having two definitions for one feature effectively results
> > in an undefined feature again, that authors should never use (and
> > implementors not implement) ...
>
> The idea is that implementations will transition to having the new
> behaviour.  

Well, there will not be a miracle that old implementations will transition
as well - and for a few features my tests indicate, that there are sometimes
viewers, that follow correctly the definitions of SVG 1.1.1.
Obviously we cannot say, that this is wrong now, what was correct for about 10 
years.

> There will of course be a time during which some popular 
> implementations follow the First Edition’s requirements and some follow
> the Second Edition’s.  

Yes, this may take 5 to 10 years until the old viewers are not used anymore,
but this depends on the progress of new viewers. If we compare the
capabilities of the adobe plugin with that of current viewers (like Opera, 
WebKit, Gecko, Batik/Squiggle it is still an alternative, especially because
older documents often depend on it and not on current viewers, having
often quite different problems).

And there are SVG tiny 1.2 viewers as well, they are up to date and for
them and the related documents changes of definitions in 1.1 do not
apply anyway, until this is aligned again, it may take more than 10
years - or maybe 5 years after SVG 2 becomes a recommendation
and SVG 1.1 and SVG 1.2 are not relevant for authors of new documents
anymore.


> Specifying version="1.1.2" doesn’t actually help 
> work around that; implementations will not look at the attribute and
> switch behaviour.

But everyone looking in the source code of a document can see, what the
intended meaning of the document is, this can help to update of to find an
appropriate viewer, for example the adobe plugin for older documents.
At least, with this the documents containing such incompatible features
still have a defined meaning.
More information is always useful, even if not used by everyone.
And obiously viewers could warn, that they have implemented another
behaviour.

For example if someone wants to update in 10 years some documents
to SVG 2, the information about the intended meaning of the document
can be pretty relevant for the update. And this does not depend on the
question, what is displayed by which viewer version, it only depends
on the version information of the document.

>
> We (the Working Group), when making incompatible changes, judge that the
> change’s importance outweighs breaking existing content.  If it is a
> major feature that a lot of existing content uses, then that will argue
> against making the change in the first place.  If it is an edge case or
> something that is not used by much content, then it makes it easier to
> change.  If we want to correct past mistakes/bugs in SVG, then we have
> to make such tradeoffs.

To fix mistakes and bugs is different from replacing already existing
definitions by other definitions without indicating the change by a
change of the version indicating. Features with bugs are are defined in
the past, therefore no problem to define them for the future properly.

Contradicting new definitions means always a lot of work for authors
having already documents using such a feature.

Up to now my estimate is, that I have in the order of 50 documents
conflicting with SVG 1.1.2. If such changes concering animation are
realised, this number will increase, maybe more than 100 documents,
maybe more than 200 documents, depending on which proposals of 
Brian are realised.

If there is no other version indication, I have to think for example what
to do with my tests, following currently SVG 1.1.1. Ok, they are often
SVG tiny 1.1 and I have to analyse, if this depends on the first edition
or on a current edition of SVG 1.1. Well, a lot to do, to find all related
files not only in my test area, but within a huge amount of other documents
of my tutorials, art gallery, a wikibook etc and to decide, what to do with
those documents, not to publish anymore, if the application is not possible
anymore (in case of wiki content to replace with an empty file maybe) or to
warn users to use an older viewer after sniffing the user agent - if it is a 
script.
All of my documents and tutorials are written to align with a 
specification/recommendation, not with a specific behaviour of a viewer. 
I think, this is one purpose of such recommendations to allow authors
at all to write defined documents, independent from bugs in viewers.
In tutorials known bugs of viewers are often mentioned, but because the 
bugs can change with each  viewer version, this is no base for explanations
and meaningful documents.

I don't know currently, what to do, but this takes a lot of time I could use
for more interesting things else. Mainly I need to remove all features with 
more than one definition per SVG version. Features with contradictions or
bugs I never used, therefore those are no problem, whatever is defined
in SVG 1.1.2 and was not in SVG 1.1.1. For tutorials and the wikibook
maybe I have to replace examples about corrputed features with a warning
about the problem of conflicting definitions.


>
> In this particular instance (discrete to-animation), the specification
> change would align with implementations.  That should result in less
> content breakage than if we kept the specification as is and convinced
> implementors to fix the bug.

Because most viewers interprete it wrong currently, there should be
practically no content anywhere using such features.
This is one of the reasons I have so many tests in my test suite, that
authors can see, which features can be considered to be totally
broken and should not be used.


>
> > It is a difference to fix bugs in the second edition or to
> > define things, that are undefined in the first edition or to fix
> > contradictions in the first edition compared to a situation with a
> > change of a defined behaviour.
>
> You could say that if we define behaviour that was previously undefined
> or ambiguous, then content should not have been relying on it in the
> first place.  

Yes.

> The consequences are the same, though: as implementations 
> change to follow the rules in Second Edition, content that relied on the
> undefined behaviour going a different way will break.  

It cannot break, because the undefined features had no defined
behaviour, therefore authors could not expect any specific behaviour.
Authors have to expect, that undefined features behave differently
in different viewers. If it does not matter - no problem. For example
the behaviour of stroke-dasharray in combination with some other
stroke properties and different path types - if one only needs a 
somehow dashes path, no problem, that the appearence is undefined 
in detail. But if one needs a precisely defined behaviour, one cannot use 
this feature. 
Therefore for a few features it is mentioned explictly in SVG tiny 1.2 
and the SVG 1.1.2 draft, that the behaviour is undefined. 
Obviously, if authors need a defined behaviour, they
will not use such a feature.

> The same 
> judgments need to be made to decide whether to specify one way or the
> other.

If there is another definition in SVG 1.1.2 than in SVG 1.1.1, this is quite 
different. In both cases the behaviour is well defined, there is just no
way to decide from the document, which behaviour was intended.
Therefore authors should not use such features in the future and
additional if they have already published documents using such a
feature, they should erase such documents or replace with workarounds
not using the feature to get well defined documents again.

Olaf

Received on Wednesday, 30 March 2011 10:16:05 UTC