W3C home > Mailing lists > Public > www-svg@w3.org > March 2005

Re: reply to CSS WG comments on SVG 1.2

From: Dean Jackson <dean@w3.org>
Date: Tue, 8 Mar 2005 22:19:46 +1100
Message-Id: <002d9966652c379111a3214bf6214204@w3.org>
Cc: www-svg@w3.org
To: Bjoern Hoehrmann <derhoermi@gmx.net>


On 8 Mar 2005, at 11:56, Bjoern Hoehrmann wrote:

> * Dean Jackson wrote:
>> The current plan is to deliver SVG Mobile 1.2 (aka Tiny 1.2) as a
>> complete specification. We received a lot of feedback (on SVG 1.2 
>> Full)
>> saying that a "list of changes" isn't very readable, and some comments
>> saying SVG Mobile 1.1 should be a standalone spec.
>>
>> Therefore, you'll probably see:
>>
>> - SVG Mobile 1.2 as a complete specification
>> - SVG Full 1.2 as extensions to SVG Mobile 1.2
>
> How would this address the feedback that a list of changes is not very
> readable? It seems that this would make the list of changes even longer
> and the specification thus even less readable. Except maybe if features
> included in SVG 1.1 but not in SVG Mobile 1.2 are not included in SVG
> Full 1.2 directly, but rather through some kind of reference to SVG 1.1
> in which case you might list fewer changes but mix changes to more
> specifications, which, I am afraid, would make it less readable, too.
>
> Isn't it much more reasonable to merge SVG 1.1 and SVG 1.2 which would
> then yield in a complete specification where people do not have to read
> SVG 1.1 and SVG Mobile 1.2, and (continue to) organize SVG Mobile 1.2
> simply by saying it is SVG Full 1.2 if it had only these features, just
> like SVG Tiny 1.1 and SVG Basic 1.1 (and pretty much all other profile
> specifications) are organized?

It might be reasonable, but it is more of a pain to implementors.
There are more people implementing Tiny than Full, and seeing as
Tiny is a subset of Full, it makes sense to implement in that
order. Reading a huge specification and then working out which
bits are not needed is not much fun.

>
> Or maybe I misunderstood you and this is actually a temporary solution
> to progress SVG Mobile 1.2 faster along the Recommendation track as SVG
> Full 1.2 will be delayed for some reason, and the specifications would
> later be merged as outlined above?

Right. The main priority is getting SVG Tiny 1.2 progressing.
SVG Full 1.2 still may be a complete specification -- that hasn't
yet been decided.

Dean
Received on Tuesday, 8 March 2005 11:19:51 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT