Re: [SVGMobile12] more on data types

Hi Robin,

www-svg-request@w3.org wrote on 01/11/2006 09:38:58 AM:

> On Jan 11, 2006, at 14:53, thomas.deweese@kodak.com wrote:
> >    I personally can't believe the WG has made this change.  It 
> > means that no compliant renderer can inform users that they 
> > have made a mistake because of course they haven't they have 
> > simply indicated to the UA to ignore the value of the attribute.
> 
> It isn't the job of a renderer to inform users of errors in the 
> content. That's the job of compliance verifying tools. 

   Well except as I point out above the WG has defined it such that
there isn't a error, it's just an attribute that needs to be ignored.
So I'm not sure what your compliance tool is going to do.

> UAs aren't things that are made for developers, they're made for 
> users. Users don't care, and they shouldn't.

   The users of some UA's don't care the users of other UA's do
care.  Shouldn't the WG leave it up to the UA implementer to decide
if their users care?

> But neither of the above are the most important reason for 
> considering that the halt and catch fire approach of 1.1 was wrong, 
> and needs changing. The major problem it has is versioning, and 
> deployment of content using new versions.

   So the WG has deprecated the 'version' attribute?  Or is
the WG officially blessing marking content as version="1.2" and
including elements/attributes from version 1.3/2.0 of the SVG
specification.

> If you want to create content that uses features from a new version 
> but will degrade reasonably well to older versions the only approach 
> defined by 1.1 is to use switch. This is impractical at best, and 
> experience shows that authors simply don't use it.

   Well, as I recall Adobe Illustrator output does make quite a bit of
use of it - to protect it's proprietary stuff.  Also in many cases you
will want to provide an alternate 'fallback' rendering of the 'extended'
content - which would still require the use of the switch element.

> Switch does have its uses, but wrapping everything in a conditional 
> is hardly better than testing navigator make and version in scripts 
> as used to be done in HTML.

   Actually I would consider it much closer to feature testing 
(especially with the 'requireFeatures' test attribute), and feature
testing appears to be widely considered to be the 'best' way to
handle this issue.  One major problem is that currently svg doesn't
provide very detailed feature strings.

> This new approach means that deploying new content is much more 
> straightforward. 

    As is subverting the specification.

> If you want the previous B&D approach, it's still 
> available by setting the version attribute. No functionality is lost, 
> we've just taken reality's feedback into account.

    True in only the most inane sense.  I certainly hope you
aren't deluded enough to think this is really an answer.

> Incidentally, the TAG's work on versioning concurs that the 
> MustIgnore strategy in vocabulary design is sound. It's also in line 
> with strategies adopted by other WGs for their vocabularies.

   Then please deprecate the version attribute.  If the intent is
to allow any content anywhere then there is absolutely no reason to
have a version attribute.

   I was always under the impression that the whole point of
the version attribute was so that UA's could up front decide that 
they couldn't really handle the content (i.e. they had no hope of 
being conformant) and thus fall back into 'display what I can' mode.

   I would expect similar behavior from 'incomplete' implementations.
But I really see no reason why an implementation that knows the complete 
element list for SVG 1.2, see's the version="1.2" and still should be 
forced to allow 'unknown' elements in the SVG namespace - other than
to allow for vendors to stick proprietary extensions into the SVG 
namespace.

> A spec can't stop vendors being stupid.

   I'm not worried about the stupid vendors, "evolution" tends to 
take care of them.  My concern is about intelligent vendors who
intentionally use required behavior like this to gain an unfair 
advantage in the marketplace, given the Web's history I think this
is a fairly valid concern.  With the new rule there is no reason for
a vendor to identify extensions by namespaceing them.

Received on Thursday, 12 January 2006 13:05:49 UTC