Copia

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

Kudos to Ruby boosters for building awareness of the language. It's now truly inescapable. That's undoubtedly a good thing. The fewer languages-that-don't-suck people are aware of, the better. For my part, though I've never been the slightest bit interested. I've also not really had any occasion to express my non-interest. I have had colleagues push me hard to look at Ruby, and once or twice I've done so,. I've found that it's definitely a nice language, but not a big enough improvement over Python to be worth the effort, and just annoying enough in some ways to discourage me from making any extra effort to soak it in.

Today I ran across a Weblog posting with many points that echoed my attitude and I figured, what the hell, that's good for a "co-sign".

In "Why I Like Python more than Ruby" Mark Ramm writes:

Don’t get me wrong, I like Ruby. And it’s not particularly difficult to read. But the philosophy of the language designers led to design choices that emphasize writability over readability. And in that department I think the advantage has to go to Python. Python lists are easy to use, but more importantly I understood all of the list methods and how to use them in the matter of a few min. Perhaps Ruby’s arrays are more powerful that Python lists, but so far I’ve yet to find something that can be done in Ruby that can’t be done easily in Python.

As I think about it even the things people complain about in Python like the explicit self, or significant whitespace are designed to with readability in mind. [emphasis mine]

I think possibly the only Python complaint that really resonates with me is the raggedness of its scoping. Nested scopes and closures help, but there are still patchy spots (advantage Ruby, I hear, thanks to blocks). I'm sure I'm forgetting other Python annoyances, but oft-cited complaints such as the GIL, Unicode API, explicit self and significant whitespace don't bother me one bit.

In comments Karl Guertin says:

In order to get me to switch languages, I have to get some sort of big advantage to make up for the loss of expertise. As a long time Python programmer, I’ve never felt compelled to use Ruby. I’ve read through why’s guide and poked at Rails, but in the end I don’t come up with enough to merit a switch. I’m sure a number of Ruby programmers are in the same boat for Python, and I think that’s fine.

The languages I’m currently investigating (Concurrent Haskell, Erlang, Clean) provide strong concurrency support, which I believe is the next frontier of programming due to the upcoming multi-core machines. In the Python community, Stackless provides concurrency primitives though I don’t think it can take advantage of multiple cores. Is there a concurrency effort in Ruby? All the Ruby news I hear gets drowned out by Rails.

Yeah. Rails seems great as far as it goes, but I'm not even much for Web frameworks in Python, let alone deciding to switch language just to use a framework. I'd be just as likely to start loving Java because Eclipse is neat.

I'm by no means wedded to Python, but if I do make the switch away, it would be to a truly fresh language, not just an incremental change of view.

[Uche Ogbuji]

My usual trick for creating a "What's changed" summary in my projects is to check CVS for commits since the previous release. SO if the previous release was 24 October 2005 I run

cvs log -NSd ">2005/10/24"

It would be nice if I could do the same thing while specifying the last revision, rather than a date. I wish I could do:

cvs log -NSr<last-rev>::HEAD

but that seems to work only for numerical revisions rather than tags. Does anyone know of any neat hacks to achieve this? Note: if you prefer to advocate Subversion, that's OK, but at least be sure to specify the precise command to do this with SVN so that others can benefit from the example.

Note: this is coming up for me now because I'm wrapping up the packaging for 4Suite 1.0b3 release. One huge new feature: Full DTD support for all the parsers (written in C by the indefatigable Jeremy). One big fix: build support for 64 bit Intel architecture machines.

[Uche Ogbuji]