Re: Wikipedia CTO speaks on SVG

~:'' ありがとうございました。 wrote:

> Perhaps someone with greater diplomatic skills than me could read and 
> comment on the enhancement bug:
> http://bugzilla.wikimedia.org/show_bug.cgi?id=3593

I think you are diluting your case there by campaigning for complex 
interactive SVGs as well as simple static ones.

The only real issue I have with simple ones is that it is not just SVG 
that has title information in the image, even if very few  people use 
it, and that title information is not the same as alternative text 
(SVG's approach to that is to require text to XML text nodes, so that it 
survives stripping of tags, although that assumes a multi-namespace 
document, not an object/embed relationship, and that linear reading 
order is respected), and embedded title information doesn't help if the 
image is never fetched.

(I would have liked static SVG to have become the standard way of doing 
line drawings in HTML a long time ago, but IE has blocked this, probably 
to keep vector diagrams limited to Office.)

For complex images, I think there are many real issues relevant to 
Wikipedia.  Security and size are definitely issues, but also:

- Wikipedia needs to work in multiple media, particularly print.
- Original research is not allowed and very large dynamic SVGs are
   likely to be original research, if they are not copyright violations.
   E.g. a detailed map of the UK pretty much has to be produced by
   collecting GPS readings (original research) or from OS maps (pretty
   much certainly a violation of database copyrights (not US) and maybe
   other copyrights.  Original research belongs in Wiki sources, not in
   Wikipedia.  Machine readable source material should be linked, rather
   than embedded.
- All information must be traceable to sources, but there are no
   standards for associating facts in complex animations with the list of
   references, nor for identifying what constitutes a fact in the
   presentation, so as to allow the equivalent of {{fact}} (a macro that
   inserts [citation needed] and also flags the page for review) in text
   documents (failure to adequately source is a big problem in
   Wikipedia).  I don't think labelling the sources in the SVG source
   code is enough; they should be obvious to normal users of the page, in
   the same was as sources in text articles should be.
- Material needs to be easy for any contributor to change, and for
   complex SVG that needs to be below the level of simply deleting the
   whole if you disagree with it.  This requires programming skills that
   are not universal amongst Wikipedia editors.
- Changes need to be visualized in a way that is easy to perceive; even
   providing an SVG oriented file difference might not be enough, because
   of the programming skills needed to see the results.  Without that, it
   becomes difficult to locate subtle vandalism, point of view changes,
   and well intentioned but wrong information.

I did have some concern that you were trying to take control of user 
agent behaviour, but on closer reading, that didn't seem to be the case. 
  In this respect, complex interactive animations would require user 
interface standards developing, or a Wikipedia API to abstract them.  If 
someone did want to provide a complete SVG API, or even one that was 
standard except for client side rendering SVGs, the licencing of the 
source material means that they are free to construct their own web 
site. It should, even, be possible to fetch the revisable form material 
dynamically, although I expect that would be discouraged, as it requires 
CGI processing, whereas most normal page accesses are cachable.

Up to now, most Wikipedia authors have maintained relative semantic 
purity to a surprising extent, so one shouldn't need to do too much 
interpretation of embedded HTML in order to retarget for something 
radically different from HTML, although you may have to re-write a lot 
of higher level macros.


-- 
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

Received on Thursday, 17 January 2008 08:57:30 UTC