Doug Schepers <> wrote on 10/14/2009 11:52:12 PM:
>
> I will be happy to advise and even do some of the heavy lifting to help
> resolve these matters, and any others of an SVG nature. I'm pretty good
> at writing spec text, and I can even be taught simple tasks. I'm new to
> OASIS, and I'm not sure what the next steps are (forming a subcommittee,
> maybe?), so any advice is welcome.
>
First I think we need to motivate our work in this area. Why are we doing
it? What is the benefit of doing something more meaningful with SVG?
I think the arguments may be:
1) SVG is experiencing something of a resurgence in interest. It is now
supported in most web browsers and looking forward to HTML 5 we would
expect it to be even more widely used.
2)There are benefits to the end user to be able to easily share data
between the document world and the web world. For example, the ability to
drag & drop a SVG graphics from a web page into an ODF document would be
cool. It can also help with conversion of ODF to HTML 5.
3) Further, to the extent that web-based editors like Google Docs (and
others) become more popular, the runtime toolkit of the document editor
will likely already include an SVG editor. So it will be far easier for
such editors to write vector graphics in SVG format when saving an ODF
document.
4)As SVG becomes more prevalent, we'd expect to see more people with
skills in this area, more code libraries and components, both commercial
and open source, more clip art libraries, royalty bearing and free, etc.
So essentially, the network effects of a common format standard.
Any other good arguments for why we want to do something here?
Further, I think we want to consider the various degrees we can progress
our use of SVG:
1) Verify that what we are using of SVG today is done in a sensible way,
and certainly not in a way that conflicts with the SVG REC.
2) Allow SVG graphics as first-class objects in ODF document, much as we
do MathML.
3) Use SVG more widely, such as being the preferred vocabulary for vector
graphics throughout ODF, including places where we currently have another
vocabulary.
Anything else?
Note: I'm not saying we do all this, but we should consider the
cost/benefit of these kinds of changes in ODF-Next.
The technical concerns I have are generally how SVG would relate to
document concepts in ODF. Three examples (and there are likely more like
this):
1) Relationship of text in SVG and text in ODF. How do the style
vocabularies relate? ODF generally uses the XSL:FO text styling
vocabulary. A use case might be for a user to be able to change a named
style and have all text with that style to change its attributes,
regardless of whether the text is in a paragraph or an SVG graphic.
2) Interactions of SVG graphics and change tracking. Users do not expect
change tracking for embedding objects, but if we progress to have inline
SVG, then it would be reasonable to track changes to graphics. How would
this be done?
3) Relationship of SVG and SMIL, which is used in presentations to
describe animation.
To have SVG really work as a first-class citizen in ODF, we need to figure
out the above.
But I should set expectations -- the ODF TC members are generally
"heads-down" on getting ODF 1.2 out to public review, and with the
upcoming ODF Plugfest and OpenOffice.org Conference. So it will be very
difficult to get the bandwidth to engage in a broader SVG discussion until
mid-November. You've joined us at "crunch time". And we probably won't
be actively working on ODF-Next until early next year. But let's do what
we can do.
-Rob
