Re: [SVGMobile12] more on data types

Hi Thomas,

On Jan 12, 2006, at 14:05, thomas.deweese@kodak.com wrote:
>> 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.

It's ignored by user agents, content checking tools are a different  
class of products. A content checking tool that didn't detect that an  
attribute was not conformant to the schema, the microsyntaces, the  
prose, etc. would be a very poor one. I would expect a good one to  
actually know about new elements introduced in 1.2 but red-flag them  
if you asked it to check against 1.1. In fact a quality content  
checker would also red-flag things that are perfectly conformant, for  
instance repeating the same property with the exact same value of  
every child of a <g> (and I can't count how many tools do this),  
orange-flag defining a gradient outside of a <defs>, etc.

There is a difference between non-conformant content that causes the  
document to be in error (e.g. non-WF XML), non-conformant content  
that is unknown/unsupported and is ignored, and conformant content.  
For each of those a user agent (intended for users) should behave  
differently from a content checker or producer (intended for  
developers and their ilk).

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

I think there should be as high as possible content-interoperability,  
so the behaviour of user agents should be well defined. The behaviour  
of content checkers however is another topic, I'm not sure it would  
be useful for the WG to constrain how developer tools work.

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

No, if you use the version (or baseProfile) attribute there is a  
requirement that if it is a version or profile unknown to the UA it  
immediately provide a highly perceivable notification that the  
content is likely to be misrendered. This allows the content author  
to clearly indicate that she doesn't want people to try to view the  
document if they can't, and that they do so at their own risk if they  
do. This is very close to requiring all features (except that the UA  
can still try to render the document provided the user has been  
notified that there's a problem).

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

The switch element isn't deprecated, and it certainly has its uses.  
That being said, as soon as you start hand-coding -- as many people  
do -- it's already a lot to ask of developers that they know the  
features of SVG that they need, if they also need to know which  
version they came in then we're asking too much IMHO.

The idea is that one can (and should) use switch for critical content  
that needs to be rendered lest the document be useless, but shouldn't  
need to for chrome (and if your chrome fails, it shouldn't cause the  
important message you're conveying to blow up).

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

It's one way, I don't think that it's that widely considered to be  
the best, or else I really don't see why Java still doesn't have a  
standard pre-processor (and heck knows it would be useful sometimes).

>> This new approach means that deploying new content is much more
>> straightforward.
>
>     As is subverting the specification.

There is very little a spec can actually do to prevent people from  
subverting it. No matter how well the spec is defined, nothing  
prevents a vendor from subverting it, and if that vendor has enough  
clout others will have to follow no matter what. Have you tried to do  
a test run on a large sample of SVG that's out there, say on Open  
Clipart? I've been running rather intensive tests of SVG compressors  
that originally expected to operate on conformant SVG and I can tell  
you there isn't much of it. Any of that could have turned into  
subversion.

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

Yes there is, see above. Besides the point is not to allow any  
content anywhere, it's to provide versionable content with much  
lesser difficulty to developers. Random content anywhere that does  
not use namespace facilities is not conformant, for instance it won't  
validate against the schema. All that's been really changed is the  
way user agents handle these.

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

Again, see above.

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

If a UA sees version='1.2' it means that if it knows all of SVG 1.2  
it can proceed without alerting the user that there is a problem. It  
does NOT mean that the content is guaranteed to be 100% 1.2, in fact  
it could contain some 1.7 or 2.4 content, simply that 1.2 is the  
level at which the document is known to be minimally useful.

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

The rule you are complaining about was pretty much only really  
implemented to a solid extent (that I know of) by Batik. Any  
intelligent vendor could have gained an unfair advantage in the  
marketplace, and still could right now. So what can the spec do about  
this? Apparently nothing, or very little (there are other ways  
though). At least we're making versioning more practical on the Web  
at large, and content authoring easier.

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

Received on Thursday, 12 January 2006 15:11:23 UTC