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 15:55:36 UTC