W3C home > Mailing lists > Public > public-cdf@w3.org > August 2005

[CDF Framework 1.0] Appendix D MIME Type thoughts

From: Jeff Schiller <codedread@gmail.com>
Date: Mon, 15 Aug 2005 10:43:17 -0500
Message-ID: <da131fde05081508431bb6bf65@mail.gmail.com>
To: public-cdf@w3.org

Appendix D discusses the many issues surrounding MIME types for
Compound documents.

I am not in favour of a new MIME type to describe CD content.  It has
been stated that the Compound Document uses EXISTING languages and the
CDF simply describes the rules for these languages to mix.  You are
not defining new content, you are only defining the rules in which the
content mix.  It is NOT a new MIME type.

If you introduce a new MIME type, that is the equivalent of draconian
error handling:  it's all or nothing.  Either a UA supports CD rules
and understands the new MIME type or it doesn't and the UA won't
render anything useful (think IE and XHTML).

If you do not introduce a new MIME type, then if I include a
image/svg+xml into a application/xhtml+xml document (via
xhtml:<object>) it is up to the UA to handle it as best it can.  If it
cannot support CD content, then it handles it as browsers do today
(i.e. no specific focus rules, link behavior may be undefined, etc)
and the user is at least able to have a limited experience with the
content.  If it can support CD content, it is supported when I
reference the SVG image in the XHTML <object> and the user gets the
best experience possible.

If I use CDI by including SVG entities right in the root XHTML
document and the user agent cannot handle SVG content, it would ignore
the svg namespaced entities.  If it does handle SVG content, but not
CD content, it would handle it as best it is able (similar to above)
and the user is at least able to have a limited experience with the
content.  If it handles SVG content AND the CDF/WICD profiles then the
user gets the best seamless experience possible.

Given decision 2 discuission, it seems that the MIME type would only
be generic (the only thing that makes sense to me) and thus, it would
not be able to give concrete information about what type of content is
mixed so a new MIME type will not be useful anyway.  In my very humble
opinion, introducing a new MIME type only complicates matters, it does
not help.

Introducing a new MIME type will also lead you into the XHTML limbo
that we have today:  if the majority of deployed web browsers do not
support it, no one will author content for it (whereas if the UAs need
to deal with as best they can today, then we can at least deploy the
content with the knowledge that some UAs will get it perfect while
some UAs may get it partially right and will work towards implementing
and others will have to let plugins deal with the content separately
like IE+ASV does today).

Thus, my vote is for Option #4 "0-mime-prof-parm":  no new MIME type,
use the profile parameter as its advantages (clearly defines root doc
type, clearly defines cdf type) seem the best.  I do not understand
what the disadvantages mean:

"No way to indicate support for just framework" => what would this
mean exactly?  A browser handles just the framework but not XHTML or

"Maximizes occurrences of content/metadata mismatches. UAs may need to
sniff anyway" => if content is mismatched the UA will need to sniff
regardless of the MIME type

The basis for my opinion is that we need to strive for incremental
improvements, not "flip-the-switch" type upgrades where without CDF
support the user gets nothing.

Received on Monday, 15 August 2005 15:43:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:47 UTC