W3C home > Mailing lists > Public > public-uwa@w3.org > January 2008

Re: Short-Term DIAL Evolution

From: José Manuel Cantera Fonseca <jmcf@tid.es>
Date: Mon, 14 Jan 2008 17:13:20 +0100
To: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Cc: Ubiquitous Web Applications Working Group WG <public-uwa@w3.org>
Message-id: <478B8A20.3010800@tid.es>

Rotan Hanrahan escribió:
> OK. Looks like we are actually thinking the same thing. I just got the impression from your original message that you were proposing that policies would be in the source document (because you started by saying "Add some markup..."). Glad to see that in reality we are thinking alike.
>  
> It might be cleaner for browsers to apply style/policy without an intermediate, or the origin server, being involved. But there are cases where it would be better done before getting to the browser. 
Indeed !. Our adaptation policies will be mainly intended for execution 
at the server side. I'm not foreseeing browser vendors implementing 
something different than CSS and HTML 5 :))
That's the reason why I wouldn't like to extend CSS for our purposes
> Suppose, for example, that there was a policy that said that pages containing more than 10 <h1> elements must be split into sub-pages of no more than 4 <h1> elements each. This would be done to reduce both the complexity of a page (to improve rendering) and its size (to avoid excessive memory and bandwidth usage). If this had to be done on the client then you'd only achieve the improved rendering, but you would have failed to avoid memory and bandwidth problems. So there's a good argument for allowing such things to be be processed on the server too. In the days of the DIWG we agreed that adaptation could take place anywhere along the delivery path, and this is what I'm describing.
>   
of course ! The same issue appears when you use CSS Media Queries for 
doing adaptation ...
>  
> ---Rotan.
>
> ________________________________
>
> From: José Manuel Cantera Fonseca [mailto:jmcf@tid.es]
> Sent: Mon 14/01/2008 15:48
> To: Rotan Hanrahan
> Cc: Ubiquitous Web Applications Working Group WG
> Subject: Re: Short-Term DIAL Evolution
>
>
>
> Hi,
>
> See inline. I think we are on the same wavelength :)
>
> Rotan Hanrahan escribió:
>   
>> When I say "represented as styling", I don't necessarily mean using CSS, in which case we wouldn't have to engage with the CSS group. What I am saying is that policies should not be knitted into the markup, if possible.
>>     
> +1 !
>   
>> A policy has general applicability, and it should be possible to change a policy without having to edit the document(s) to which the policy applies. That's something that can be done in CSS today, where you edit the CSS document independent of the markup that references it.
>>  
>>     
> +1 !
>   
>> However, where CSS falls down is in the coupling between document and style. The styled document can contain a link to the document that provides the styling. If you want to use an alternate stylesheet then you either edit the reference in the markup document, or you make the URL act as a dynamic source of CSS. It would have been nice if it were possible (in the absence of dynamically generated CSS) to couple a markup document with a stylesheet without having to edit either of them.
>>  
>>     
> Yes I was thinking on the same too
>   
>> But to my point, if we are talking about policies, I'd prefer to see them outside the document, much like the approach used by CSS today.
>>  
>>     
> +1 !
>   
>> Regarding the complexity of implementing a process that can apply/manipulate/filter styles at the server side, I can tell you from my experience that it the approach works (at least when you are dealing with the adaptation of styles for multiple delivery channels).
>>     
> Yes of course, you can filter out things, but wouldn't it be cleaner if
> we leave CSS for "direct browser interpretation" and we think on upper
> layer mechanisms?
>   
>> Since the approach is already proven for style, I think it could also be used for policy.
>>     
> Sure !!
>   
>> I am not, however, claiming that it is the only viable approach. For something less functional, a "minimal set of use cases" (to use your words), alternatve strategies should certainly be examined. The MyMobileWeb experience will be valuable here.
>>
>> ---Rotan.
>>
>> ________________________________
>>
>> From: José Manuel Cantera Fonseca [mailto:jmcf@tid.es]
>> Sent: Mon 14/01/2008 15:15
>> To: Rotan Hanrahan
>> Cc: Ubiquitous Web Applications Working Group WG
>> Subject: Re: Short-Term DIAL Evolution
>>
>>
>>
>> Hi Rotan,
>>
>> Representing policies as CSS styling rather than markup has a lot of
>> problems in terms of standardization and implementation. Wrt
>> standardization we would need to deal with the CSS people and web
>> browser vendors.
>>
>> In terms of implementation, and assuming that web browsers are not going
>> to implement that style properties, it would mean that adaptation
>> solutions would need to filter the "extended CSS properties". My
>> experience with that in MyMobileWeb says to me that perhaps we could
>> avoid using CSS for that purpose.
>>
>> The use case you mention about images and paragraphs is a very good
>> example of the necessity of standard pagination policies.
>>
>> Best Regards
>>
>> Rotan Hanrahan escribió:
>>  
>>     
>>> 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 16:20:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:21 GMT