RE: Device Independence Working Group publishes DIAL primer

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: www-di-request@w3.org [mailto:www-di-request@w3.org] On Behalf Of José Manuel Cantera Fonseca
Sent: 11 October 2006 11:05
To: Rhys.Lewis@volantis.com
Cc: www-di@w3.org; w3c-di-wg@w3.org
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: 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