Re: [SVGMobile12] About vector graphics and other specification

Jean-Claude Dufourd wrote:
> Non vector graphics domains in question include (but are not limited to) 
> Connection API, mandating gzip encoding, mandating PNG and JPEG image 
> decoding and mandating OggVorbis audio decoding.
> 
> Whereas I understand that the clauses about non-"vector graphics" items 
> may be needed to ensure the interoperability of content within a 
> particular application domain, the presence of these items within a 
> single "SVG Tiny 1.2" profile will hinder the reuse of SVG within other 
> application domains where a particular audio or image encoding (or 
> compression, or API) has no relevance.

I cannot think of a single domain that would at the same not need 
interoperable user agents and yet need a standard. If there are 
communities in need of non-interoperable vector graphics user agents, 
surely they can choose any ad hoc solution they please?

> As a result, I would request the definition of 2 separate kinds of profile:
> - a vector graphics profile, which could be the current SVGT1.2 profile 
> purged of any non vector graphics item (elements and attributes syntax, 
> semantics, rendering model and specific APIs)

How would something which had no concrete syntax (can't be read), no 
semantics (can't be machine processed), no way of being rendered (can't 
be human processed), and no API (can't be manipulated) be of any use on 
the Web? It would seem to me that Pythagoras, Bézier, and a few others 
have already done a damn good job at defining what would remain and that 
the SVG WG could only mess it up.

> This would broaden the scope of the excellent work done within the SVG 
> WG, by defining an interoperability point for the currently envisaged 
> applications while allowing later opimal reuse of the purely vector 
> graphics part of the specification within other application domains, by 
> other industrial fora.

Concrete examples of what such reuse could be would be helpful.

-- 
Robin Berjon
   Research Scientist
   Expway, http://expway.com/

Received on Saturday, 21 May 2005 14:43:31 UTC