RFC: Re: To what content type does longdesc refer?

A question has been raised as to what sort of a resource can be cited in
the URI-reference which is the value of a LONGDESC attribute.  Should the
XHTML specification, for example, add language addressing allowed or
disallowed content types for resources so referenced?  Comments from GL and
PF are requested at this time to inform the WAI position taken before the
HyperText Coordination Group.

Proposed resolution: 

The content which results when the resource identified in a LONGDESC
attribute is recovered is subject to the provisions of the WCAG 1.0
together with the referring document.  This is how the obvious
suitability-for-use concerns should be addressed, and not through any
clause in the specification of the referring format restricting the content
type of the resource served under the cited URI.

Notes:

At the time of the release of HTML 4.0, it was contemplated that at least
HTML would be used for LONGDESC resources in addition to plain text.
Growth to audio formats was envisioned but SMIL was not available yet.
With the current repertoire of W3C Recommendations, it is both consistent
with the goals of the WCAG 1.0 and a friendly amendment over plain text or
plain HTML that a LONGDESC reference be to a SMIL composite containing both
sound and text representations of the description, for example.  The point
here is that the set of MIME types which can beneficially and legitimately
serve as carriers of long descriptions cited as the LONGDESC attribute of
an image in a WCAG 1.0 compliant document is diverse and growing.

The transparent content negotiation mechanism of HTTP makes it easy for an
HTTP URL to identify a resource which is served in a variety of forms
including diverse Internet Media Types.  This is a characteristic of URIs
in general.  A URI gives you reasonable assurance that you will get the
resource that the author referred to; it does not in general give you any
assurance about the type of what you get when you recover the identified
resource.  The fact that this gets repeatedly misunderstood is a large part
of the moviation which led Dan Connolly to write the draft Note at
<http://www.w3.org/Architecture/state.html>.  The Web came to be the
dominant medium of exchange for information on the Internet precisely
because Tim Berners-Lee consciously and effectively purged barriers to
interoperation from the base architecture.  This is why the standard for
inter-document reference is the URI which is types-blind.
In the existing HTML 4.0 the specification language is potentially
misleading.  Starting at
<http://www.w3.org/TR/REC-html40/types.html#type-content-type> it says
"this attribute specifies the content type..." as if the value of this
attribute were normative.  This is not so.  Everywhere the attribute is
used, the semantics is "advisory content type," connoting that the
attribute is informative and not normative.  This is not accidental but
necessary to maintain the standard mode of interoperation between documents
and URIs and thereby the radical openness and connectedness of the Web.

Although providing assurance of suitability for use of the LONGDESC
resource is a laudable goal, putting normative type restrictions on
URI-reference uses in Web documents would be overkill and could prove to be
a damanging retreat from the existing openness of an architecture which has
done so much to bring people and documents together in a whole new way.


Therefore it is not appropriate for LONGDESC at this time to depart from
the basic practice of allowing any Web document type to refer to any Web
document type in any URI-reference.

Application profiles such as the WCAG which are applied above the basic
types layer may introduce suitability-for-use requirements which ripple
throughout a functional unit of web content such as a website, but these
requirements should not be migrated to the content types layer at this
time.  The scopes for which conformance to the WCAG can be claimed are
describe to be at least the examples of "page, site, or defined portion of
a site" at <http://www.w3.org/TR/WAI-WEBCONTENT/#Conformance>.  The type
specifications such as HTML refer to unit chunks of resource and do not
come with assurances of the availability or suitability of the recovered
content of the resources, at least not formally.  

It is reasonable to expect this at a service level; if an HTML document if
offered from a server and it cites via LONGDESC a resource not available to
the users of that server then the WCAG provision requiring a description of
an image may be reasonably consdered not to have been met.  This is a
service failure, a failure of the server to make the complete resource
available, not a type violation.

Al

Received on Wednesday, 25 August 1999 12:50:31 UTC