RE: Device Independence Working Group publishes DIAL primer

Hi José,

Further to Rhys's response:

Examples in the primer:

I used the <col> element in line with the XHTML 2.0 table 'best practice'-

Cited from http://www.w3.org/TR/xhtml2/mod-tables.html#sec_30.2. :
"The advantage of using the colgroup element is that authors may logically group multiple columns. By grouping columns, the author can apply rules across the entire group. The author can also apply column width balancing across the group of columns. For example, if the author has a table with five columns and the author divides the table into two column groups, one with three columns and the other with two columns. The author could define the first column group to consume 300 pixels and the second column group to consume 100 pixels. Each column within the first column group would be 100 pixels wide and the remaining two columns would be 50 pixels wide. If the author added embedded col elements, she could force one or more columns to be a specific width and the remaining columns within the group would be evenly divided within the remaining allotted width."

So, yes, you could just use <th> - however this column recognition and grouping, as per the XHTML 2.0 spec, should help the DIAL processor identify and remove the columns irrelevant to the current delivery context. I also think it makes the authors intention more 'human readable'.

The resulting XHTML 2.0 output (following DIAL processing) may well decide to remove the <colgroup> and its child <cols> (unless of course they need to be retained for CSS styling, as described in the citation above).

Content selections within the content:
I'm afraid I haven't looked in depth at Morfeo (but will when I get a chance!)...but it would appear that DIAL allows the author to control if content should appear at all, rather than which version of that content. I'm guessing that Morfeo is relying on all fragments of page content to be retrievable from URLs so that a suitable version can be included. Whilst I see that working for images and objects, does that not imply that text should be included from a URL, if you want to provide multiple versions (such as a truncated text teaser for narrow devices)? DIAL does not predicate this, rather the author can provide the content within the DIAL page and then state which text version to show under which circumstances.

Also DIAL allows for content selection on the device itself (e.g. for mobile, select a low bandwidth stream because I've just lost UMTS coverage), not just the server. Finally another design driver for goal was to be 'implementation independent', so that if the architecture of a author's system changes from, say, .Net to Java,  then the author's intent is not lost. All that is needed is for the DIAL processor to be swapped.

Hope that helps, thanks for your comments and information

Best regards
Kevin



-----Original Message-----
From: w3c-di-wg-request@w3.org [mailto:w3c-di-wg-request@w3.org] On Behalf Of Rhys Lewis
Sent: 11 October 2006 10:32
To: "José Manuel Cantera Fonseca"; www-di@w3.org
Cc: w3c-di-wg@w3.org
Subject: RE: Device Independence Working Group publishes DIAL primer


Hello Jose, 

Thanks for your mail. Let me try and answer your questions and concerns here. As I'm sure you are aware, the publication of the specification and primer is just the start of the process for these specs. There are reviews where everyone has a chance to comment formally. And, of course, there is the opportunity to participate in the group. We would welcome participation from more people with adaptation solutions.

DIAL and XForms:
The short answer is yes, and this is because DIAL is a profile of XHTML Version 2 which does itself include XForms 1.1.

Content selection mechanisms within the content:
Actually, we (Volantis) have examples of where content selection within content is useful. However you are absolutely correct that most adaptation systems also have the means to select resources externally. In the forthcoming DISelect primer, we will show examples of how DISelect could be used to achieve some of the things you mention. Commercial solutions, like Volantis's and MobileAware's have additional mechanisms. The mapping from a reference within content to a particular version of a resource is very much a proprietary one at the moment, differing across different implementations. We have not yet attempted to address standardisation of such mechanisms within DIWG, though it is likely to form the basis for future work. The first time that we will address this will be with work on explicit representations of page layout. That item will be in our new charter.

Selection rules by inclusion:
Yes! Absolutely! We've not addressed this in the specifications, but I will be covering it in the DISelect primer.

Examples in the primer:
On the specifics of the particular choice of the <col> element in the table, I'll ask Kevin Smith, the author of the document to comment.

Selection Rules and Repositories:
The short answer is yes. We've been very careful in DISelect to try and decouple the markup and expressions from the underlying implementation of the delivery context (device characteristics if you prefer). The reason is that we want selection to be possible regardless of the implementation of the XPath functions in DISelect expressions. Now recalling that DCI is an API to the device on which it is running rather than a full-blown repository API, we think that implementations of DISelect that run client side could be built on DCI. Of course, the question of whether or not there will be browsers that directly support DIAL is a little different. There seems little appetite from browser vendors at present. We see the main benefit of DIAL as a standard markup for authors that can be supported by a variety of different adaptation engines. 

DIAL and Compound Documents:
DIAL is a compound document. So all of the work that CDF has done in sorting out how to represent such things, their discussions on MIME types etc is appropriate and we will be taking it into account as we progress the work. DIAL itself is a profile composed of multiple modules. With the latest revision of XHTML Version 2, it looks as though there are two modules at present. Those are XHTML Version 2 and DISelect. We're tracking recent changes in XHTML Version 2 and will update DIAL in line with them at the appropriate time. Our next charter shows that we anticipate adding a module for SVG though we've not discussed whether this will be optional or mandatory. 

XHTML 1.1 vs XHTML 2 vs DIAL
DIAL is a profile of XHTML 2. It adds content selection
XHTML 1.1 and XHTML 2 are substantially different. There are many new features in XHTML 2. The major change is that old style HTML forms are not in XHTML 2. XForms replaces them.
DIAL is a set of device independence extensions for XHTML 2. Since not all users of XHTML 2 will be interested in the device independence extensions, we've created a profile (or compound document if you prefer) that adds them for those who want them. If such features become generally regarded as useful in future, then we could see them form part of a future version of XHTML. However, at present and for the foreseeable future, it seems likely that device independence features will remain of most interest to authors and that browsers will continue to run with earlier versions of XHTML.


Once again, thanks for your comments.

Best wishes

Rhys

-----Original Message-----
From: www-di-request@w3.org [mailto:www-di-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: www-di@w3.org
Subject: Re: Device Independence Working Group publishes DIAL primer


Dear all,

Here are some of my doubts regarding DIAL:

+ Does DIAL imply that the DIAL processor must support all the XForms 
features i.e. a DIAL processor must be a full-compliant XForms processor?

+ I don't see the value of putting the select mechanisms inside the 
presentation. These are content selection rules that can be put outside 
or can be implicitily deduced.
In Telefonica's open source product, MyMobileWeb, 
(http://www.morfeo-project.org/mymobileweb) this is done by means of 
providing different resources in different folders and managing a unique 
identifier (independent of the physical file finally delivered to each 
device).

+ IMHO the developer should have the possibility of referencing the 
selection rules by inclusion and by reference. Are you planning any 
future work regarding this issue?

+ Why use the <col> tag in the table ? The selection rules could be 
specified in the <th> tag?

+ The selection rules, could they refer to a static device description 
capability (for example against our future DDR) or also refer to a DCI 
property ?

+ Is DIAL modularized so it can be used to produce compound document 
formats resulting from the combination between DIAL and other markups?

+ What are essentially the differences between XHTML 1.1 and XHTML 2 and 
DIAL?
Wouldn't it be better to specify a set of additions to provide device 
independence and add them to XHTML 2, possibly combining them?

Best Regards

Max Froumentin escribió:
> Hi www-di,
>
> The DIWG is proud to announce the publication of the 
> Device Independent Authoring Language Primer, available at
>
> http://www.w3.org/TR/2006/WD-dial-primer-20061010/
>
> Abstract: This document provides an introduction to, and the benefits
> of, DIAL (the Device Independent Authoring Language). It summarizes
> the concept of device independence, the scenarios in which it could be
> used, and the considerations in order to achieve that goal. It then
> describes the role of DIAL in ensuring the delivery of content
> suitable for the user, device and inherent circumstances in which it
> was requested.
>
> Feedback is welcomed on this list.
>
> Max Froumentin
> for the DIWG
>
>
>

Received on Wednesday, 11 October 2006 11:28:27 UTC