RDFa Drupal Open Graph

 I have added a page to collect RDFa links over at http://aule-browser.com/rdf/index.html.

There will be a separate parsing section for PEG's, Icon 9.5, ObjectIcon 2.3, Rebol 3, Logtalk and PROLOG (and SNOBOL in C ?)

The number of essential links is now near twenty - and this is in English only.

It is still not clear to me how searchmonkey will fare as Yahoo! moves to using Bing for search.

SearchMonkey for documents was already infuriating for me due to SearchMonkey being restricted to Flash documents ( given my work in Curl markup for literary documents as http://aule-browser.com/poets/ and http://aule-browser.com/phil/ .)

I still have to get a post together on RDF with Curl documents.  RDF is largely associated with the one XML syntax - but there is nothing about RDF triples that requires XML.  Curl documents which are embedded in HTML pose no problem in general since the RDF can be expressed in the embedding object element.  Curl documents which are themselves .curl applet files offer unrestricted tagging in the initial {applet } expression so the Curl runtime itself could be adapted to export RDF.  The matter is less obvious for the {include } of documents which are .scurl text files at the top-level within applet files.

The root Curl document, when unspecified, is a TextFlowBox, but with Curl 7.0 there are now ParagraphVisual and TextVisual classes. To quote from the documentation for the parent class,

This class provides a public API for accessing the contents of text-containing objects to be rendered by text containers such as TextFlowBox.

At the moment there is no option available for a popup action such as "Print" which would offer RDF triples rather than the content - and these for the Visual container "hit" as opposed to the entire "page". A Visual would need an option such as exports-rdf? and possibly a tie to a triples validator.

The whole matter ties back to whether Curl is suited for CMS - if a suitable server-side partner emerges as IT continues its slouch towards HTML5.  Or Flash 12.1 or ...

I had thought that Drupal could be a candidate, but after some exploratory efforts I lean towards a Gemstone + Seaside 3.0 option ( pul-ease do not mention Scala Lift ... )  I still keep an eye on Wicket (Hippo?), Zope/Plone and Ruby candidates such as Nesta.

Generating Curl 7.0 web content from Seaside 3.0 on Pharo 1.0 beta

Yesterday I used a 3.0 install on the Pharo 1.0 beta to generate non-HTML (in my case that is Curl markup )

I would not say that is any easier that before 2009 Camp Smalltalk ( I started from scratch - it still took me hours to track down everything )

Anyone trying this must remember both gotchas:

WASystemConfiguration clearAllDescriptions.

WARenderer resetDefault.

But since WARenderer is an HTML subclass which always resets the default renderer class to itself, that >>default method had to change.

The main nuisance is that methods >>textHtml or >>textPlain are in many critical places instead of a default rendering type ... and of course many key methods for error and redirect still output raw HTML.

Now to see what headaches appear as Pharo and Seaside evolve - given the wide-spread changes still required to accommodate a default rendering MIME type other than plain text or html.

Curl and GemStone are such a natural match that the game still looks to be worth the candles.

The Future of Curl

Over at Curl I have added some comments to an invitation by Richard Monson-Haefel to weigh-in on improving Curl.

Divining the future of Curl means thinking outside the box. Here's a few attempts.

Pair up Curl as a client-side to Gemstone as has been done by Seaside.

Beef-up Curl on the client-side by getting serious about the future of expression-based languages: if there is not room in the marketplace for ICON, UNICON, REBOL and Curl then look to partner with the remnant of the ICON team at U. of Arizona.

If the Curl team cannot partner-up, then look to go beyond one of those languages by having more effective goal-oriented programming than UNICON or more user-friendly parsing than REBOL.

The option of viewing Curl as a platform and not a language seems to close off many avenues unless Curl, the platform, is able to embrace languages such as ICON which appear to be in need of a new home.

Or is there a niche for Curl in the future of Perl with Parrot, or Ruby with an industrial-quality VM, or distributed OZ?

One interesting place to look is GROK and what they are looking to do with Python ZOPE. That project alone might ensure the future of ZOPE.

Then there is RDF. Somehow RDF has become tied to clunky XML implementations or worse. Even now that W3C has embraced "sparkle" for RDF Data Access, we need not ignore the prospects for Curl as a potentially RDF-friendly language. Prima facie, ICON back-tracking and REBOL paths make either look more promising as a language. But Curl, the platform, could be a powerful starting point for a more language-neutral approach to RDF triples. Mozilla XUL has moved away from RDF (blame XML there, where the 'X' is for 'Xtra-heavy' rather than eXtensible.) The real-issue is how to effectively provide metadata. As more people look to HTML and XHTML itself as the answer, Curl appears to be a natural: Curl has always been metadata-friendly.

Curl CSPD could even be used to help ensure that meta-data that would disclose too much would be suppressed where privacy is an issue (think blogging in China and i-journalism most anywhere.)

Cool Curl 'live' code widget

Over at eclectic-pencil I have a post on a very cool Curl widget that rivals almost anything I have ever seen expand and collapse on a web page.

What I neglect to mention is that in the example, the only code to create the XMl tree is this:

   let xmldoc:XDMDocument =
{build-xml preserve-whitespace? = false, loc}
|| ...
{XDMTreeControl open? = true, xmldoc.root}

Which you would be hard-pressed to beat in Seaside for Smalltalk or in Groovy. Concise.

TiScript also has an alternative DOM and some nice features as a JavaScript alternative, but Curl 5.0 is a mature, full RIA product with 'live' code for inspection and a focus on the client-side. It is almost Smalltalk but it was also built for the web (in fairness, Curl goes about as far back as Smalltalk VisualWave.)

The only cool but alive technologies as neglected as Curl 5.0 must be Gemstone/S and Rebol 2.6.3 ... and the latter is soon to be 2.7.x with 3.0 in the wings ...

Watch for a Seaside for Gemstone/S beta in the news soon ...

PS For people living on AIR and FLASH, Rebol/FLASH went 2.0 today ...