<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10pt"><div>I suppose this depends on who the target audience for using Mallard is but playing devils advocate a little, this solution looks overly complex.<br><br>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.<br><br>Ian<br></div><div style="font-family: Courier New,courier,monaco,monospace,sans-serif; font-size: 10pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span
 style="font-weight: bold;">From:</span></b> Shaun McCance &lt;shaunm@gnome.org&gt;<br><b><span style="font-weight: bold;">To:</span></b> mallard-list@projectmallard.org<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, 3 August, 2010 14:46:47<br><b><span style="font-weight: bold;">Subject:</span></b> Revisiting Conditional Processing<br></font><br>Back in March, I outlined a proposal for conditional<br>processing in Mallard:<br><br><a href="http://projectmallard.org/pipermail/mallard-list_projectmallard.org/2010-March/000002.html" target="_blank">http://projectmallard.org/pipermail/mallard-list_projectmallard.org/2010-March/000002.html</a><br><br>Basically, there would be an if attribute you could use<br>on any block element. That attribute would contain an<br>XPath expression. The block element would be displayed<br>only if the expression evaluated to true.<br><br>We would define some extension functions to make this<br>more useful. The one
 I proposed was mal:key, which<br>would take some key ('os', 'arch', etc) and return<br>some value.<br><br>After talking with Phil and Milo at GUADEC this last<br>week, I'd like to propose doing this as an extension<br>instead. Here's the extension namespace:<br><br>xmlns:if="<a href="http://projectmallard.org/if/1.0/" target="_blank">http://projectmallard.org/if/1.0/</a>"<br><br>You could then do conditional processing like so:<br><br>&lt;p if:if="if:key('arch') = 'x86_64'"&gt;64-bit FTW&lt;/p&gt;<br><br>We still need to define keys. I'd also like to define<br>the if:supports function, to test whether the tool<br>supports a particular feature. This would take a URI<br>that identifies the feature, and always return true<br>or false. This could be used, for example, to show<br>an action link only if the action is supported.<br><br>Doing this as an extension, however, means we need<br>to have good fallback behavior for tools that don't<br>implement the
 extension. If you just use the if:if<br>attribute on a block element, a non-supporting tool<br>will ignore the attribute and always display the<br>contents.<br><br>So we'd provide a more complex form, using extension<br>elements if:choose and if:when. Example:<br><br>&lt;if:choose&gt;<br>&nbsp; &lt;if:when if="if:key('distro') = 'fedora'"&gt;<br>&nbsp; &nbsp; &lt;p&gt;You're running Fedora.&lt;/p&gt;<br>&nbsp; &lt;/if:when&gt;<br>&nbsp; &lt;if:when if="if:key('distro') = 'ubuntu'"&gt;<br>&nbsp; &nbsp; &lt;p&gt;You're running Ubuntu.&lt;/p&gt;<br>&nbsp; &lt;/if:when&gt;<br>&nbsp; &lt;p&gt;I don't know what you're running.&lt;/p&gt;<br>&lt;/if:choose&gt;<br><br>A supporting tool treats this as an "if, else if"<br>construct. It displays only the first if:when that<br>is true. If and only if all if:when elements are<br>false, it displays any bare child block content.<br><br>Here's the beauty of it: Because of the way Mallard<br>defines behavior for
 unsupported block extensions,<br>a non-supporting tool will only display the fallback<br>content.<br><br>So the if:choose and if:when elements would be the<br>complete extension that plays nicely as an extension,<br>and the if:if attribute would be a shorthand you can<br>use if you're specifically targeting tools that you<br>know support conditional processing.<br><br>I think this addresses run-time conditional processing<br>really nicely, with good fallback behavior, and without<br>complicating the base Mallard specification.<br><br>Thoughts?<br><br><br>-- <br>Shaun McCance<br><a href="http://syllogist.net/" target="_blank">http://syllogist.net/</a><br><br><br>_______________________________________________<br>Mallard-list mailing list<br><a ymailto="mailto:Mallard-list@projectmallard.org" href="mailto:Mallard-list@projectmallard.org">Mallard-list@projectmallard.org</a><br><a
 href="http://projectmallard.org/mailman/listinfo/mallard-list_projectmallard.org" target="_blank">http://projectmallard.org/mailman/listinfo/mallard-list_projectmallard.org</a><br></div></div>
</div><br>



      </body></html>