Device Independence Working Group publishes DIAL primer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Device Independence Working Group publishes DIAL primer

Max Froumentin

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

Reply | Threaded
Open this post in threaded view
|

Re: Device Independence Working Group publishes DIAL primer

JOSE MANUEL CANTERA FONSECA

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
>
>
>  



Reply | Threaded
Open this post in threaded view
|

RE: Device Independence Working Group publishes DIAL primer

Rhys Lewis

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: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: [hidden email]
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
>
>
>  





Reply | Threaded
Open this post in threaded view
|

Re: Device Independence Working Group publishes DIAL primer

JOSE MANUEL CANTERA FONSECA
Many thanks Rhys for your quick reply

See my comments inline

Rhys Lewis escribió:
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.
  
This could make more complicated the process of implementing DIAL at the server side
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.
  
ok, although I don't understand now the relationship with layout definition
Selection rules by inclusion:
Yes! Absolutely! We've not addressed this in the specifications, but I will be covering it in the DISelect primer.
  
I was referring to two different mechanisms:

+ The selection rules are embedded in the XHTML document
+ The selection rules are in another document and they are referenced from the XHTML document ¿Is this allowed in the current spec?
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.
  
ok
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. 
  
yes but XForms adoption could be a barrier for content adaptation solutions
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. 
  
Here is the problem you are tied to the XHTML 2. Let's the developer decide how they combine the languages, including SVG.
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.
  
So, why not concentrating only on the profile and not defining "a new language" and forcing implementing XFORMS, for example. I'm going to explain it. So if DIAL only defines language formalisms to achieve device independence, let's decouple that formalisms from the underlying presentation language. I would like to use the DI formalisms (content selection, etc) in a XHTML 1 page.

Also in the WAF WG we are in process of standardizing a declarative format for application and user interfaces (DFAUI), and I would like to use the DI formalisms inside the DFAUI.

Honestly, I think the term and language DIAL could confuse the market. We only need to define extensions and that extensions should as orthogonal as possible and not to be coupled with an specific language (XHTML 2) .

Once again, thanks for your comments.

Best wishes

Rhys

-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: [hidden email]
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


  
    






  

Reply | Threaded
Open this post in threaded view
|

RE: Device Independence Working Group publishes DIAL primer

Smith, Kevin, (R&D) Vodafone Group
In reply to this post by Rhys Lewis

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: [hidden email] [mailto:[hidden email]] On Behalf Of Rhys Lewis
Sent: 11 October 2006 10:32
To: "José Manuel Cantera Fonseca"; [hidden email]
Cc: [hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: [hidden email]
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
>
>
>  







Reply | Threaded
Open this post in threaded view
|

RE: Device Independence Working Group publishes DIAL primer

Rhys Lewis
In reply to this post by JOSE MANUEL CANTERA FONSECA

Hi Jose,

 

Thanks for your additional comments. Here are my responses.

 

Complexity of implementation:

Clearly, XHTML 2 is a bigger language than earlier XHTML versions. However it is much better suited to device independent authoring. It also has really good facilities for metadata integration which is important to many mobile operators and for advanced adaptation. XForms is a much better forms platform and much easier to adapt to a myriad of devices. Interestingly, there are many implementations of XForms in existence. The XForms working group maintains a list at http://www.w3.org/MarkUp/Forms/#implementations. There are also implementations within adaptation engines. Volantis, for example, has such an implementation.

 

Layouts:

The work is at a very early stage. Just think of the ability to define a layout independent of styling and content. Selection might be used to pick different versions of a layout definition for use in different circumstances. Similarly, different versions of a CSS stylesheet might be chosen for use in different circumstances. I’ll include a CSS example in the DISelect primer. Maybe best to wait for the next version of that document.

 

Selection rules by inclusion:

Both mechanisms you describe are supported. Inclusion itself is a matter for the host document. XHTML 2 has one mechanism. We think we may also want to add XInclude, but have not really looked at that fully yet.

 

Selection rules and repositories:

We chose to go with XHTML 2 a long time ago because of its superiority as a basis for an authoring language. Group member companies have considerable experience of trying to build adaptation solutions on older XHTML versions and the difficulties that are presented. We concluded that XHTML 2 was a much better proposition. As I’ve pointed out there are plenty of XForms implementations and those adaptation companies that have already implemented them have not encountered any particular difficulties.

 

XHTML 1 vs XHTML 2:

Actually, practical commercial experience with real customers suggests a preference for XHTML 2 facilities. Far from being a problem, XHTML 2 is an advantage.

 

Profiles:

There is nothing whatever to prevent you using DIWG developed formalisms in other language profiles. It’s just that we’re not working on those right now. The companies in the working group, who have many years of commercial DI and adaptation experience, chose to base the DIAL profile on XHTML 2 as the best available version for DI purposes. However, we also deliberately chose to make DISelect a completely separate specification, so it can be combined with other host languages. Hence, if you want to create a profile of, say, XHTML 1 and DISelect, you can. We expect to pursue the same approach with other modules. In other words, where we create something new, we’ll build it so that it can be used outside DIAL, even though we use it within DIAL.

 

Names:

Naming things is difficult, and can be very personal. Actually, our experience with explaining this to our (Volantis) customers is that they understand it very quickly.

 

Structure of extensions

Let me re-emphasize that the extensions we have defined in DIWG can be used outside DIAL. The improvements in device independence of XHTML 2 over XHTML 1 are a matter for the HTML group. However, in large part, these are due to their decision to use XForms.

 

Best wishes

 

Rhys

 

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 11 October 2006 11:05
To: Rhys.Lew[hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: Device Independence Working Group publishes DIAL primer

 

Many thanks Rhys for your quick reply

See my comments inline

Rhys Lewis escribió:

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.
  

This could make more complicated the process of implementing DIAL at the server side

 
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.
  

ok, although I don't understand now the relationship with layout definition

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

I was referring to two different mechanisms:

+ The selection rules are embedded in the XHTML document
+ The selection rules are in another document and they are referenced from the XHTML document ¿Is this allowed in the current spec?

 
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.
  

ok

 
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.
  

yes but XForms adoption could be a barrier for content adaptation solutions

 
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.
  

Here is the problem you are tied to the XHTML 2. Let's the developer decide how they combine the languages, including SVG.

 
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.
  

So, why not concentrating only on the profile and not defining "a new language" and forcing implementing XFORMS, for example. I'm going to explain it. So if DIAL only defines language formalisms to achieve device independence, let's decouple that formalisms from the underlying presentation language. I would like to use the DI formalisms (content selection, etc) in a XHTML 1 page.

Also in the WAF WG we are in process of standardizing a declarative format for application and user interfaces (DFAUI), and I would like to use the DI formalisms inside the DFAUI.

Honestly, I think the term and language DIAL could confuse the market. We only need to define extensions and that extensions should as orthogonal as possible and not to be coupled with an specific language (XHTML 2) .

 
 
Once again, thanks for your comments.
 
Best wishes
 
Rhys
 
-----Original Message-----
From: [hidden email] [[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: [hidden email]
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
 
 
 
    
 
 
 
 
 
 
  

 

Reply | Threaded
Open this post in threaded view
|

RE: Device Independence Working Group publishes DIAL primer

Smith, Kevin, (R&D) Vodafone Group
In reply to this post by Max Froumentin

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: [hidden email] [mailto:[hidden email]] On Behalf Of Rhys Lewis
Sent: 11 October 2006 10:32
To: "José Manuel Cantera Fonseca"; [hidden email]
Cc: [hidden email]
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: [hidden email] [mailto:[hidden email]] On Behalf Of José Manuel Cantera Fonseca
Sent: 10 October 2006 16:36
To: [hidden email]
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
>
>
>