Re: Core Presentation Attributes

Hello Håkon,

Thank you for your comments on our draft Core Presentation Attributes 
document (archived at:
http://lists.w3.org/Archives/Public/www-di/2003Jan/0002.html).

Here is a response to many of the points you made, on behalf of the 
Device Independence WG:

 > I suggest adding maximum widths (and for the sake of symmetry,
 > maximum heights as well) to the list of requirements.

We understand your motivation for wishing to describe limits on image
size. There seem to be two choices in handling maxima, minima, ranges or
other constraints on the values of attributes.

One it to introduce a full expression language (as done in Conneg) to
define such constraints. This would be beyond the scope of the current
CPA proposals, but might be added as part of a profile description (such
as in a CC/PP vocabulary).

The other is to introduce special additional attributes for selected
constraints, such as max-width and min-width in Media Queries. While
Media Queries had syntactic restrictions that led to this choice for
expressing maxima and minima, it is not an easily extensible approach to
expressing constraints and triples the number of attribute names
required for numeric quantities.

 > Target image colors is also, in our experience, useful.

Yes, we will need to define attributes to express color spaces in the
CPA recommendation. The CPA Requirements document avoids defining
exactly what attributes will be included in the recommendation.

 > Alternative textual alternatives would be great, but I doubt it's a
 > realistic scenario. HTML's longdesc attribute hasn't seen much use.

Agreed, but the need becomes greater as the variety of presentation
devices grows. It may be handled server-side if browsers don't handle
text alternatives effectively.

 > I'm unsure how useful it is to request certain image formats: GIF and
 > JPEG are the VHS of the web, and I'm not terribly keen on seeing
 > JPEG-2000 introduced.

Image format (MIME type) negotiation is already supported in HTTP accept
headers. Devices should be free to state what they will accept. Servers
(or transcoding proxies) should be encouraged to offer sufficient
alternatives to meet the needs of the devices.

 > I would find it awkward if CPP takes on the design of a system which
 > will be completing with Media Queries as long as Media Queries is in
 > CR stage, and I therefore suggest limiting CPP to upstream uses.

The Core Presentation Attributes recommendation will not include
specifying any particular protocol or context in which the attributes
should be used, whether 'upstream' or 'downstream'. Indeed, we hope to
show the correspondence (where possible) between the Core attributes and
Media Queries features, while providing a way of mapping the same
attributes between other notations such as XML and RDF.

This use case is motivated by future chartered DI work on Document
Profile, picking up early suggestions from the HTML WG:
    http://www.w3.org/TR/xhtml-prof-req/

 > Another use case I have problems with is #2 which describes a "request
 > for a static formatted (HTML) resource". By definition, HTML is not
 > static and we should not try to make it static. E.g., it should still
 > be left to the UA to determine where line breaks should go.

This may be badly expressed in the draft, and we will change it to make
it clearer. The intention was to define how large the 'viewing window'
might be. This defines the viewing area, either in a single browser
window, or of a pane in a portal, or of a fixed-size display such as a
projector. It would still be possible for the UA to scroll the HTML
content within this viewing area if it cannot all be viewed at once.

I know that Opera and some other browsers do their best to lay out the
content for small devices, often in the face of extreme difficulties
created by authors who compose for fixed, absolutely positioned HTML
layouts. Our hope is that, if better information were available to web
applications about the size of viewing area available, authors would be
encouraged to provide designs (if necessary alternative designs) that
worked on a greater range of devices.

 > In general, I think there is important work to be achieved in this
 > area. The low-hanging fruit is very accessible and the apple tree is
 > very tall. I therefore suggest aiming for a very simple "upstream"
 > specification, no more than 10 pages.

We will try to produce a simple Core, which could well find its first
application in 'upstream' protocols such as CC/PP. The danger, as
always, is to avoid including more attributes than absolutely useful.

We will keep you informed as the draft moves forward, and hope you will
continue to provide such welcome feedback.

Regards,

Roger Gimson
DI WG Chair

-- 
HP Laboratories, Filton Road, Stoke Gifford, Bristol BS34 8QZ, ENGLAND
roger_gimson@hpl.hp.com   Tel: +44 117-312-8167  Fax: +44 117-312-8925

Received on Thursday, 13 February 2003 09:40:28 UTC