Re: Content Type

Hi,

CC/PP looks really interesting, but I couldn't find more support
details than
http://www.w3.org/2003/07/ccpp-SV-PR/test-suite-20030827/implementation-report.html,
which is dated July 2003.

Filed an enhancement bug for Firefox
(https://bugzilla.mozilla.org/show_bug.cgi?id=331327), and added a
Wikipedia article. Please fill in with details, if you have time! Then
let's see what happens :)

Mark Birbeck:

> I've been looking at CC/PP, and I have to say that it looks to me to be
> capable of solving this problem. I have no idea what the general feeling is
> towards it though, and to implement it fully does require a little bit of
> extra processing in the browser so I don't know whether it's going to gain
> support. But it is a generalisable way of adding all sorts of information of
> the type you're describing, through to how big your screen is, whether you
> have a mouse fitted, and so on.
> 
> However, there is a kind of interim step that might be possible, without
> implementing the full thing.
> 
> CC/PP involves a browser sending a URL to the server in an HTTP header, that
> points to information about the device. The 'full' implementation then
> allows further headers that modify the larger group of settings. It's
> generally used in mobile environments and in that case it's often quite
> simple, since generally anyone with an xyz phone will have the same
> capabilities as the next person.
> 
> However, it's not absolutely necessary for the server to retrieve the
> document pointed to by this URL--it can say that it knows this URL to
> indicate a 'profile' that is made up of certain information, and then just
> carry on with that. So one possible interim technique would be to create two
> or three 'known' URLs that indicate the presence of XForms and/or SVG. At
> some point if a device adopts CC/PP properly, then it would just send a
> different URL to point to 'real' data, or it would use the modifications
> feature.
> 
> > -----Original Message-----
> > From: www-forms-request@w3.org 
> > [mailto:www-forms-request@w3.org] On Behalf Of Victor Engmark
> > Sent: 22 March 2006 10:10
> > To: www-forms@w3.org
> > Subject: Re: Content Type
> > 
> > 
> > Allan Beaufour:
> > > 
> > > On 3/21/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> > > > > I was wondering if XForms had a Content-Type associated 
> > to it such 
> > > > > as application/xforms+xml. I have not seen any on the 
> > IANA website 
> > > > > nor anywhere else. Please forgive me if I haven't 
> > looked carefully 
> > > > > enough.
> > > >
> > > > As Victor said earlier, it doesn't have such a type. What 
> > we need is 
> > > > actually some kind of 'sub-type' mechanism that lets us know that 
> > > > the browser has a plug-in installed--there are a number of 
> > > > suggestions on how to solve this, but nothing has been 
> > firmed up yet.
> > > 
> > > Yeah, we've also discussed it for some time. Adding a user-agent 
> > > identifier is not really "the right thing" to do, because 
> > you need to 
> > > know what combination of languages that the client supports, i.e.
> > > XForms+XHTML, XForms+SVG, XForms+XHTML+SVG, etc. etc... 
> > This is a task
> > > for the CDF working group
> > > (the Firefox bug for it is here:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=279729)
> > 
> > 2 cents:
> > 
> > Isn't it time for user agents to start reporting more fine 
> > grained which standards they support? The HTTP Accept header 
> > doesn't provide enough information to know whether a document 
> > will be understood at all, and can lead to quite a few hacks, 
> > specially on sites using cutting edge technology, such as SVG or AJAX.
> > 
> > For an example, take a look at the correspondence between the Firefox
> > 1.5.0.1 Accept header
> > (text/xml,application/xml,application/xhtml+xml,text/html;q=0.
> > 9,text/plain;q=0.8,image/png,*/*;q=0.5)
> > and the support level reported at
> > http://www.webdevout.net/browser_support.php or 
> > http://en.wikipedia.org/wiki/Comparison_of_web_browsers.
> > 
> > Say that I want to serve a page with some SVG, MathML, 
> > CSS2/3, and AJAX functionality. Each of these requires 
> > different hacks to ensure that non-compliant browsers don't 
> > barf on the contents. For SVG and MathML, I can use CSS to 
> > put the advanced contents above the replacement images, or 
> > use e.g. SVG <desc> to provide replacement text. Both methods 
> > increase the amount of contents sent to the user agent, and 
> > are not really accessible - Non-visual browsers get the same 
> > information twice.
> > 
> > For CSS, countless hacks have been devised to make sure sites 
> > display the same in different browsers. So the user agent 
> > always receives more information than it needs.
> > 
> > AJAX needs to check for JavaScript support, then 
> > XMLHttpRequest support, and then must use typeof to switch 
> > between JS methods. This can easily triple the length of a script.
> > 
> > What if browsers could negotiate support with the server using e.g.
> > namespace URIs, where these would reference either a 
> > standard, part of it, or some pre-defined support level? 
> > Poof, SVG 1.1 Tiny 95% supported, CSS 3 10% supported, DOM 
> > level 2 80% supported, etc..
> > 
> > Obviously, the Accept header would be much longer, but the 
> > contents received could be reduced significantly. Also, I 
> > believe it would be easier for developers to use only Accept 
> > header switching than learning all the hacks necessary for 
> > modern web development.
> > 
> > I don't really know if this is possible, but maybe this kind 
> > of Accept header could be separated into a special HTTP 
> > reply. This would contain the URIs of the potential contents, 
> > and the user agent would send a new HTTP GET request with the 
> > modified Accept header, reporting the support levels.

-- 
Victor Engmark
>From Slashdot comment #14670100:
- I think we should start referring to the New Testament as the "Theory of Jesus". That wouldn't piss anyone off at all.

Received on Wednesday, 22 March 2006 13:29:57 UTC