W3C home > Mailing lists > Public > public-cdf@w3.org > June 2006

Re: ACTION-388: Re: [WICDMobile] Identification and [WICDFull] Identification

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 05 Jun 2006 23:31:24 +0200
To: "Timur Mehrvarz" <timur.mehrvarz@web.de>
Cc: public-cdf@w3.org
Message-ID: <op.taozemsx64w2qv@id-c0020.oslo.opera.com>

On Tue, 09 May 2006 13:13:53 +0200, Timur Mehrvarz <timur.mehrvarz@web.de>  
>> * When a new version of XHTML is issued, say XHTML 1.2, we would have  
>> to update the URI to some new string.
> I don't think we *have* to do this. While today, the WICD profile may  
> look like a maximal feature set, this will not stay this way and it  
> doesn't have to. The WICD profile would ideally even evolve into a least  
> common denominator feature set. Different agents will support more  
> features and newer specifications.

In that case it's not solving any problem.

> We need to educate authors, to only check for the "/wicd" string in the  
> profile URI and (if really required, for content depending on features  
> of a next version) to also check for a minimum date signature, like for  
> "/2007/03/" instead of "/2005/12/" (doing: year>minY || year==minY &&  
> month>=minM).

That doesn't seem to scale very well and might also clash with other uses  
of "wicd" in the profile URI that have nothing to do with our version.

>> * As pointed out, that's not only a problem for the UA, that's also an  
>> issue for content. I can currently check for WICD Full 1.0, but at the  
>> moment SVGT 1.3 is released or XHTML 1.2 and eithers makes some  
>> backwards incompatible changes I would like to know that as an author,  
>> but I can't really...
> As an author, you would like to know. OK. Using the profile date  
> mechanics, described above, we could create as many profile update  
> specifications as necessary.

None of this is in the specification at the moment and as pointed out  
above it seems not a very good approach. As an author I just want to  
publish something and not having to check wicd versions etc. For most  
content that uses SVG and is published people are not really doing any  
type of feature checking and are not requesting such functionality.

>> * It's unclear to me when UAs can add this to their Accept: header. For  
>> example, no UA supports the longdesc="" attribute on the <img> element  
>> in XHTML, yet we expect XHTML to be fully supported because otherwise  
>> the UA would not issue use this string, right? There are many tiny  
>> things that are not fully implemented which will probably not be fixed  
>> anytime soon, are we going to delay WICD until 2010 so we can be sure  
>> they are?
> Yes, we have to talk about this. One possibility is simply trusting  
> vendors.

I don't think that will work. Most vendors have different ideas about  
supporting features. Just take a look at hasFeature from the DOM and what  
browsers actually support, et cetera.

> Another one is for vendors to pass a testsuite. A testsuite will not  
> test everything, of course. It would probably not check for  
> img/longdesc. (2010 would be a little late.)

This seems like the most sensible solution, but having a testsuite that  
covers CSS 2.1, SVG Tiny 1.2, XHTML 1.1 etc. that is good enough will  
probably take until after 2010...

Anne van Kesteren
Received on Monday, 5 June 2006 21:31:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:21 UTC