Re: URIs, content adaptation, DISelect and XSLT

Hi,

Just for the record, I put into the table, some time ago, a proposal for 
separating DISelect from DIAL. I sketched it on the UWA Wiki [1].

Perhaps a combination of the XSLT approach and my suggested approach 
could suffice to get rid of the DISelect code inside the DIAL code

Best Regards

[1] http://www.w3.org/2007/uwa/wiki/DISelect-Separation

Max Froumentin escribió:
>
> Hi all,
>
> Smith, Kevin, VF-Group wrote:
>
>> Of course,
>> we can continue with DIAL which has great merits when aligned with the
>> IDEAL datatypes, but I can see that now becoming more of a CMS/device
>> aware engine language, with this XSLT approach providing a quick,
>> modular add-on to existing content markup. 
>
> Indeed, the separation of concerns is the number 1 objection to 
> DISelect: if you see content adaptation as styling, then you'll see 
> DISelect as an heresy and will instead propose a content/style 
> separation à la CSS, but server style. (I don't think that the 
> question whether the engine is XSLT or any other language is 
> particularly relevant here.) Both mechanisms are so radically 
> different that it's hard to see how the "separated" approach could be 
> explored in DISelect, other than to mention it exists.
>
> As for Dave's original question about pagination, I'm not sure how an 
> XPath function would work. Dave, could you send an example or two? One 
> way of doing it without a function is to enable pagination URI 
> parameters, like ?page=. Then when the browser requests 
> http://www.example.com, then the server which has decided to paginate 
> returns the first page of HTML, including a link to 
> http://www.example.com/?page=2. That seems to do the trick.
>
> Max.
>
>

Received on Wednesday, 12 December 2007 12:32:50 UTC