I Wish XForms was Recursively Declarative

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.

Chimezie Ogbuji

via Copia