I've become a big fan of declarative problem solving lately, which is one of the reasons I really enjoy composing web-based user interfaces with XSLT and XForms. However, I was thinking about how I would build an XForm to edit a very recursive structure, an EBNF instance as an XML document. I thought it would be nice to define a widget (an xf:group) for each of the more major components of a grammar and (in XSLT push fashion) recursively render a form for editing an instance of the grammar.
After all, XSLT was the main reason I really like the idea of schematron for document validation. The XML infoset is perfect match for capturing an EBNF, since it is purely syntactic and very recursive. So, it's a shame I couldn't take advantage of an XML-based user interface's processing mechanism (like XForms) to render an edit form in the same way an xsl:apply-template with a mode would.
Imagine:
Grammar Instance
SELECT * WHERE { OPTIONAL { GRAPH ?provenance { ?person a foaf:Person } } }
Grammar Instance (as an XML Document)
<SelectQuery> <AllVariables/> <Where> <GroupGraphPattern> <GraphPattern> <OPTIONAL/> <GroupGraphPattern> <GraphPattern> <GRAPH graphName="?provenance"> <GroupGraphPattern> <BasicGraphPattern>?person a foaf:Person</BasicGraphPattern> </GroupGraphPattern> </GraphPattern> </GroupGraphPattern> </GroupGraphPattern> </Where> </SelectQuery>
XForm snippet
<xf:group ref="SelectQuery/Where"> <xf:group ref="GroupGraphPattern" mode="push"> <fieldset> <legend>A SPARQL GroupGraphPattern</legend> <xf:apply-templates-equivalent mode="push"/> </fieldset> </xf:group> </xf:group>
Which would render a radial set of fieldsets, one for each GroupGraphPattern in the recursive structure. Somewhat related: Quadtrees in Javascript and CSS
I guess I can see how having to maintain the dependencies in this scenario would be something similar to having an XSLT processor bound to a 'live' XML instance - very expensive.