Re: [SVGMobile12] more on data types

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. UAs aren't  
things that are made for developers, they're made for users. Users  
don't care, and they shouldn't.

>    Well, if we didn't have 'tag soup' before it will now quickly
> proliferate.

With the strict rules in previous specs we already have relative tag  
soup. It's clearly not a strategy to get vendors to cooperate.

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. 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. 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.

This new approach means that deploying new content is much more  
straightforward. 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.

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.

>         Implementations are now free to add what ever new attributes &
> elements they want without having to do anything pesky like indicate
> that they are a proprietary extension by adding a namespace prefix,
> safe in the knowledge that their competitors will ignore them with
> no-one allowed to provide an embarrassing error message pointing out
> that element 'foo' is really not part of SVG.  SVG is now ripe for
> embrace and extend.

We didn't exactly get freedom from proprietary extensions with the  
strict approach. A spec can't stop vendors being stupid.

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

Received on Wednesday, 11 January 2006 14:40:03 UTC