RE: Adaption

### --- See inline.
---Rotan.

-----Original Message-----
From: Kai Hendry [mailto:hendry@cs.helsinki.fi]
Sent: 09 July 2004 10:21
To: Rotan Hanrahan
Cc: www-di@w3.org
Subject: Re: Adaption


On Thu, Jul 08, 2004 at 04:07:53PM +0100, Rotan Hanrahan wrote:
> Consider an example: CSS-MQ can select styles on the basis of some
> device properties, and sometimes these properties can only be known
> for sure at the client. But in a mobile situation, you'd have to send
> everything to the client so that it could execute its selection
> process. Not very efficient use of bandwidth, and possibly putting a
> burden on the client CPU and memory. So the alternative is to get the
> client to send the essential data toward the server side, to avoid
> comms overheads, and possibly move the processing to a place where
> there is more CPU, memory and power.

Ok, we need to draw a line here between content and style. Are you
talking about adapting content and/or style?

###--- Hard to do one without doing the other. Personally I find adapting
content to be more of a challenge, but I accept that manipulating the
content without doing something with the style can lead to bad results.
Interestingly, you can usually get away with manipulating the style
without having to manipulate the content. Here's an example: for a small
screen (or window, or viewport...) you can fit a big doc by using
content collapsing. This can be done through style (i.e. making areas
invisible until an event like a click or "mouse"-over). Alternatively,
you can collapse by moving areas into separate pages that can be reached
by clicking. The former is a style adaptation, the latter is content
adaptation. I like to think of all the possibilities.

> The picture represents a technique, but you are free to blur the
> boundaries. In fact, we hope to blur the boundaries quite a lot.

I'm not so fond of the proxy [2]. Why not a basic picture of what could
happen between server and client? Direct requests and responses. That's
the model I much prefer.

###--- It's a simple model. But only a model. The real world is a bit
more complex, so we're looking at the real world and trying to find
a better model of it. The proxy is just one instance of a model where
adaptation takes place anywhere along the path between server and client.
And this is a model that exists for real too. Which is a good starting
point. But we don't plan to stay at the starting point, so let's see
what else can be done. If you want to stay at the pure client-server
model, then fine. It's also a valid instance, but not one I would
prefer.

> It doesn't propose techniques. It explains techniques that are known,
> though the techniques are at varying levels of maturity as you will
> discover when you go "shopping" for an implementation. Pick the one
> that suits your needs and your budget. (Budget includes your time, not
> just your money.)

Shouldn't the di do more than this? Give a recommendation? There is some
techniques there which I at least think should be avoided.  It should be
a clearer guideline.

###--- And we will. Now that we have a better understanding, we are
working to create new solutions. Expect to see W3C Recommendations
from the DIWG in this area. Also, "guidelines" is something that we
have been thinking about. Something like: "how to author content so
that it is suitable for device independence". Whether we assume the
presence of adaptation, or expect the native markup to be ubiquitous is
a matter for discussion. It's early days on this one...

> PS: Nokia UA: A summary of the actual issues observed by you w.r.t.
> this UA might be of particular interest to the audience of this list.
> And if you care to expand on other UAs it might make for a very
> interesting report. Similar compliance reports have been done for PC
> browsers (mostly markup/css related).

I could do a compliance report, but it would take me quite a lot of time
and I do not get paid for producing such reports. :/

###--- Nor do I. :-)

From what I have tested [1], I can say this. Nokia UAs accept malformed
XHTML therefore you will have to expect authors to create malformed
XHTML. I am sure some people (myself included) have assumed mobile
vendors will only implement XML parsers, forcing content authors to
write well formed XHTML. This is not the case in reality.

###--- Conformance and flexibility. Always a struggle. You are right,
though. If the browsers permit sloppy markup, people will write sloppy
markup. I would like a compromise where the browser displays an ugly
warning at the top of the screen, yet continues to do its best to render
the page. That way the customer doesn't fail to get the content, and
the author is encouraged to fix the markup to get rid of the ugly
warning. Remember: say "broken" and the technical people get the blame,
but say "ugly" and the marketing people get the blame, and marketing
people have more influence so are more likely to get the page fixed.

[1] http://dabase.com/soup/
[2] http://www.w3.org/TR/di-atdi/intermediate-adapt.png

Received on Friday, 9 July 2004 05:42:15 UTC