RE: Content Type

Victor,

It is a tricky one, and I agree with you that the Accept header is not going
to be able to carry the weight of all of these things--not least because in
a compound document environment you need to be able to pass information in
both directions.

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.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

> -----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
> All generalizations are wrong.
> 
>

Received on Wednesday, 22 March 2006 10:41:02 UTC