Re: Thoughts and questions on future work

Hello WG,

On Mon, 10 Nov 2008 06:38:56 +0100, Cameron McCormack <cam@mcc.id.au> wrote:

>
> Hello WG.
>
> I thought I might write down a few thoughts and questions regarding our
> future work now that we’re (presumably mostly) done with work on 1.2T.
>
>
> SVG Core 2.0
> ------------
>
> These are the goals that I see for SVG Core 2.0:
>
>   * To really hammer out any ambiguities and lack of precision that
>     exist in 1.1 and 1.2T.

We have already a collection of ~50 proposed errata items for 1.1. I too would like to see 1.1 clarified, and while a 1.1 errata probably can't address all ambiguities it would probably be a good idea to get the errata folded into a spec and published first. Especially our goal is to rewrite the spec from ground up for core 2.0. Also note that what I'm saying is that we should publish what we have, and not continue adding new errata items at this point. Any new issues found should instead be fixed in core 2.0.

Given the above I think the work to publish a spec with the errata folded in wouldn't be too exhausting. And we could work on core 2.0 in parallell.

>   * To align SVG with the web platform as it’s being specified in
>     other groups (e.g. HTML 5).

Hear hear.

>   * To reflect on which features have been successful from SVG 1.1
>     and which haven’t, to see if we can improve them (or drop them if
>     nobody uses/needs them).

Agreed, and I think in some cases (text/fonts especially) what's needed is some clarification.

Here are a few goals I'd like to fulfill:
   
   * Define how SVG in HTML/CSS images should behave, wrt scripting, size calculation etc

   * Investigate in core 2.0 how the SVG 1.1/1.2T DOM could be improved and possibly aligned with other DOMs

   * Collect (and act on) the input from the SVG IG and www-svg wrt to features that are either misdesigned or simply missing in SVG


> Modules and mobile profiles
> ---------------------------
>
> I agree with the sentiment that we shouldn’t work on further mobile
> profiles of SVG.  Mobile devices are improving rapidly, and are at the
> point now that SVG 1.1 Full implementations on them are feasible (and
> exist, e.g. in Safari for the iPhone).

Or for that matter Opera Mobile 9.5 for Windows Mobile devices [1] (free download), which has both SVG 1.1 Full and SVG 1.2 Tiny, just like the Opera 9.5 desktop version.

> The original intent for the modules that we have started writing already
> was that they were to be used on top of 1.2T.  How does that impact us
> now that we have decided to work on an SVG Core 2.0 that will be the
> language core, rather than 1.2T?  

I'd still think that 1.2T would include large parts of what will be in core 2.0.

> There was a question of whether we
> would go back to creating a monolithic spec for SVG 2.0 instead of a
> core plus modules.  I think there are still advantages to the
> modularisation (allowing the different modules to advance in parallel
> instead of all having to move together, exporting useful functionality
> to non-SVG specs) though there is of course spec-related overhead in
> doing this.

In order to proceed with a modular approach we'd have to deal with all the module interdependencies somehow, and it would also make testing much harder, which would mean that we'd probably take longer to reach REC status on modules. 

I don't think it's impossible to tweak wording such that it becomes easier for other specs to reuse features from SVG, even if we decide that a monolithic spec is the way forward.

> If we do continue with the module approach, then we’ll want our modules
> to be used on top of Core.  The modules would then need changes to adapt
> to the goals of Core (greater precision, etc.).  The question then is:
> do we “abandon” 1.2T altogether, in terms of modules being targetted to
> it?

I wouldn't call it 'abandoning' 1.2T, and I don't think it would be a problem to let modules depend on core 2.0, unless there are particular features from 1.2T that the modules depend upon.

> If so, then the modules will be delayed until Core is ready (or
> ready enough).  Alternatively, we could continue work on the modules as
> we have them at the moment, suitable for use on top of 1.2T, and then
> revise them later (second editions? or SVG 2.0 FooModule?) once Core is
> ready enough.  We’d still have to consider whether modules that haven’t
> been started yet should still target 1.2T.

That sounds reasonable for a module that is fairly mature already, such as SVG Print, although it does say in the requirements that it's a true subset of SVG 1.2 (Full presumably). For filters, and the other modules I think I'd rather see them target core 2.0.

> Priority for modules
> --------------------
>
> As for which modules we need to be working on:
>
>   * I think there is a desire to see Print finished (especially from the
>     Inkscape people, so that they can begin using the advanced colour
>     functionality).

Right, I think that's important too.

>   * The multiple resolution functionality from the old 1.2 Full WD is
>     also something that is periodically mentioned by Inkscape folks.

Yes, I would like us to review the requirements for the feature, to see if what was in 1.2 full drafts is the best solution.

>   * Given the fact that it has been implemented, the “bling” work by
>     roc (applying SVG effects to non-SVG content) should become a
>     module soon.

I think it would be good to have that in core 2.0, and possibly try and collect all the SVG<->CSS rules in one place. It may be that a module is easier though, however I don't think such a module should depend on 1.2T.

>   * The other modules I haven’t got much of an opinion on.  (The one
>     allocated to me, Layout, I don’t think is particularly urgent.)

It is a fairly common request though, aligning shapes/text to other shapes/text without using scripting. But I think you're right in that we can't do everything at once, and that we still don't have the requirements for the feature.

> We should go through the old 1.2 Full WD again to see what features
> don’t currently map to any of the modules listed in
> http://www.w3.org/Graphics/SVG/WG/wiki/Main_Page and decide we want to
> include this functionality, and how prioritised this should be.  For
> example, the generalised flowText support has been implemented for ages
> in Batik, and people like to use it. 

Inkscape has implemented flowText too IIRC.

> But of course there is the issue
> that the CSS WG like to do text, and I thought I read somewhere that the
> CSS WG wanted to work on arbitrary shape text flows at one point.

It seems the XSL WG are much closer to actually doing arbitrary shape text flow though. The SVG WG decided at the TPAC to meet with the XSL WG at the February 2009 F2F, and they will try to co-locate their meeting.

> SVG in HTML
> -----------
>
> Where are we on this?  I guess there was discussion at the TPAC F2F, but
> since I wasn’t there I’m not up to speed.

At the TPAC the HTML and SVG WG agreed on some of the requirements for the solution. There are still requirements left to discuss.

> Recent work in CSS that has overlaps with SVG
> ---------------------------------------------
>
> We should start taking a closer look at the recent work in the CSS WG
> (such as the specs submitted by Apple) to see whether/how it applies to
> SVG, and if we need to collaborate with them to get a unified model of
> transformations (or animation, or whatever) between CSS and SVG.

We did have a short session at the TPAC about transforms, where Dean Jackson attended. The transform proposal from Canon should be in CVS, but isn't yet. I agree it would be nice to get a unified syntax.

> SVG 1.1 errata
> --------------
>
> It’d be good to finish off the errata that we have for SVG 1.1 and
> publish a second edition, before Core and the relevant modules that make
> up SVG 1.1 functionality are published.

I agree, also see above.

Cheers
/Erik

[1] http://www.opera.com/products/mobile/download/

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 10 November 2008 09:02:05 UTC