RE: Short-Term DIAL Evolution

With DISelect as a neutral (host controlled) module, it would not need to be bound to XHTML2. In this case, it could work with any language.
 
To get wider adoption for the use of DISelect, I'd like to see an XHTML1 version of DIAL. Unfortunately, the binding to XHTML2 seems to draw the wrong kind of attention, no matter how much you say that it's only used on the authoring side and doesn't necessarily determine the target language in the browser.
 
A generic policy markup might be useful, though I would see it better represented as styling rather than markup. So, for example, a style could say that a <h> should be kept with the <p> that follows, or that a <p> should avoid being paginated in the middle, and so on. What I *would* like to see in markup is some kind of proximity representation, so that two related items could be identified. In this way, if I paginate an article that references an image elsewhere on the page, the paginated version will keep the image close to its reference point. This avoids cases where the resulting pagination looks disjoint.
 
I'm still thinking about the Appearance [1] idea.
 
---Rotan
 
[1] http://www.w3.org/TR/css3-ui/#appearance
 

________________________________

From: public-uwa-request@w3.org on behalf of José Manuel Cantera Fonseca
Sent: Mon 14/01/2008 12:40
To: Ubiquitous Web Applications Working Group WG
Subject: Short-Term DIAL Evolution




Hi all,

I've been thinking on the short-term evolution of DIAL. The following
items are the result of a my own brainstorming, so feel free to discuss
them :)

+ Decoupling DIAL from XHTML 2 i.e base DIAL on different modules some
coming from XHTML 1 and some coming from XHTML 2. For example, the Role
and Access modules seem to be very stable but other XHTML 2 modules not
+ Decoupling DIAL from DISelect (i.e. perhaps making DISelect an
optional module)
+ Add some markup for simple policies, like pagination or layout (for
layout we can only address the minimum set of use cases needed for
mobile development and leave the generalization to the upcoming
Layered-UI XG)
+ Standardize some values for something like the 'appearance' property
in CSS to map between the XForms controls and its concrete
representation. It is expected that the future Concrete UI Markup will
make this more general but we can start with a very simple spec

What do others think?

Best Regards

Received on Monday, 14 January 2008 15:01:52 UTC