W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

Re: [SVGMobile12] more on data types

From: <thomas.deweese@kodak.com>
Date: Fri, 13 Jan 2006 06:32:18 -0500
To: thomas.deweese@kodak.com
Cc: robin.berjon@expway.fr, www-svg@w3.org, www-svg-request@w3.org
Message-ID: <OF0EC0FBC6.BE4FD485-ON852570F5.003B150E-852570F5.003F6102@knotes.kodak.com>

Hi all,

    One more suggestion on this point.  It appears that the model Robin 
has put forth
is that there is some minimal version of SVG that is required to maintain 
the primary
functionality of a page (let's call this is base version) and there is 
presumably a
second version of the SVG specification that is required to provide the 
full functionality
of the page (let's call this the full version).

   Thus I would suggest that a new version attribute be added, either 
baseVersion,
or fullVersion and assign the other's role to version.

   So if we had baseVersion and version, you might see something like:
<svg baseVersion="1.2" version="1.3"  ....>

   This would indicate that you need at least an SVG 1.2 implementation to
make any real sense of this document, but parts of this document use
element's/attributes/values from version 1.3 of the SVG specification.

   Thus a 1.2 implementation would know that it should ignore unknown 
stuff,
but 1.3 implementation would still be able to say - ahh I know all of the 
elements
attributes and values from SVG 1.3 - so I can be strict with this content 
(I would
go as far as to add a "SHOULD notify user of 'unsupported' values" to the
SVG specification in this case - this wouldn't force UA's to notify but 
would
offer a deterrent from adding new elements to the SVG NS).

    I don't think that needing to increment/add the full version attribute
when you start including content from a new version of the specification 
is a
large burden for authors.  Also some UA implementers might want to provide
a small notification when they only implement SVG 1.2 but the document 
uses
elements from 1.3 (if only to prod users into downloading the next version 
;).

www-svg-request@w3.org wrote on 01/12/2006 10:08:54 AM:

> 
> Hi Robin,
> 
> Robin Berjon <robin.berjon@expway.fr> wrote on 01/12/2006 09:49:07 AM:
> 
> > On Jan 12, 2006, at 14:18, thomas.deweese@kodak.com wrote:
> > >    This is possible but is not IMHO how the SVG spec is currently 
> > > written.
> > >
> > > If the WG wants to adopt your interpretation then I would suggest 
> > > making it clearer that the 'ignore' only applies to the rendering 
> > > and adding a fifth bullet to section 'C.2':
> > >
> > >         * The UA MAY display a highly visible indication that an
> > >           unsupported element, attribute, property, attribute value 
> > >           or property value was encountered.
> > >
> > >    However, given Robin's responses on this topic I doubt the WG 
would
> > > agree with your interpretation.
> > 
> > I don't see what in my reply gives you the impression that we 
> > wouldn't accept such a comment.
> 
>    Because you don't seem to accept the notion that a UA can
> warn the user on unsupported values/elements as this (if widely
> implemented) would prevent including SVG 1.3 elements in a document
> labeled as version="1.2" - something you have stated as a goal. 
> My reading of your comments indicate that you feel a UA MUST 
> silently accept unsupported values/elements.
> 
> > If you feel that the specification is 
> > unclear on the fact that content checkers can display highly 
> > perceivable indications of all sorts of things (this includes non- 
> > conformant content that would not cause a UA to stop, but also 
> > perfectly conformant things that are bad ideas as I say in my 
> > previous post) then we certainly should add something.
> 
>    Note that I say 'UA' above not content checker.  Can a Conformant
> SVG 1.2 User Agent produce a warning on 'unsupported' values/elements?
> Note that in many cases this will effectively render the content
> 'unusable' as the warning (or similar variations) may be repeatedly 
> generated due to script/animation (say script updating the 'transform'
> attribute incorrectly in response to mouse move events).
> 
>    If you add the above bullet to C.2 then my main concern on this
> point will have been addressed.  Content producers will no longer
> be able to rely on 'silent ignore' for elements/attributes not in the
> spec.  However this will go against your stated goal of allowing
> limited SVG 1.3 content in a document marked with version="1.2".
> 
> 
Received on Friday, 13 January 2006 11:32:30 GMT

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