Revisiting Conditional Processing

I suppose this depends on who the target audience for using Mallard is but 
playing devils advocate a little, this solution looks overly complex.

I like the idea, and it may suit those who understand "developer" solutions, but 
I think it will make conditional text for anyone outside that area very 
difficult to use. Many find simpler conditional implementations than this very 
confusing to use. And while no doubt flexible, this would add a level of 
complexity they (we) would shy away from and consequently it would be unlikely 
to be used.

Ian




________________________________
From: Shaun McCance <shaunm at gnome.org>
To: mallard-list at projectmallard.org
Sent: Tue, 3 August, 2010 14:46:47
Subject: Revisiting Conditional Processing

Back in March, I outlined a proposal for conditional
processing in Mallard:

http://projectmallard.org/pipermail/mallard-list_projectmallard.org/2010-March/000002.html


Basically, there would be an if attribute you could use
on any block element. That attribute would contain an
XPath expression. The block element would be displayed
only if the expression evaluated to true.

We would define some extension functions to make this
more useful. The one I proposed was mal:key, which
would take some key ('os', 'arch', etc) and return
some value.

After talking with Phil and Milo at GUADEC this last
week, I'd like to propose doing this as an extension
instead. Here's the extension namespace:

xmlns:if="http://projectmallard.org/if/1.0/"

You could then do conditional processing like so:

<p if:if="if:key('arch') = 'x86_64'">64-bit FTW</p>

We still need to define keys. I'd also like to define
the if:supports function, to test whether the tool
supports a particular feature. This would take a URI
that identifies the feature, and always return true
or false. This could be used, for example, to show
an action link only if the action is supported.

Doing this as an extension, however, means we need
to have good fallback behavior for tools that don't
implement the extension. If you just use the if:if
attribute on a block element, a non-supporting tool
will ignore the attribute and always display the
contents.

So we'd provide a more complex form, using extension
elements if:choose and if:when. Example:

<if:choose>
  <if:when if="if:key('distro') = 'fedora'">
    <p>You're running Fedora.</p>
  </if:when>
  <if:when if="if:key('distro') = 'ubuntu'">
    <p>You're running Ubuntu.</p>
  </if:when>
  <p>I don't know what you're running.</p>
</if:choose>

A supporting tool treats this as an "if, else if"
construct. It displays only the first if:when that
is true. If and only if all if:when elements are
false, it displays any bare child block content.

Here's the beauty of it: Because of the way Mallard
defines behavior for unsupported block extensions,
a non-supporting tool will only display the fallback
content.

So the if:choose and if:when elements would be the
complete extension that plays nicely as an extension,
and the if:if attribute would be a shorthand you can
use if you're specifically targeting tools that you
know support conditional processing.

I think this addresses run-time conditional processing
really nicely, with good fallback behavior, and without
complicating the base Mallard specification.

Thoughts?


-- 
Shaun McCance
http://syllogist.net/




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projectmallard.org/pipermail/mallard-list/attachments/20100809/908127b6/attachment.html>