We have published a new case study...

http://www.1060research.com/buzz/case_trimondo.html

which describes the use of NetKernel as a SOAP message/XML integration server in the Trimondo B2B portal.

We've now added a number of new forums to the forum service...

http://www.1060.org/forum/

We are pleased to announce the opening of a brand new 1060 Forum discussion service.

Whilst mailing lists have their uses we understand that not everyone wants to subscribe or has the desire to manage mass mailings.

Our intention is that over time the forum service will replace our mailing lists. It provides a permanent searchable record
and should prove to be an easier and more effective communications channel.

We hope you'll find the forum valuable and look forward to hearing from you there. To start things off the first topic is "What forums do you want to see here?"

http://www.1060.org/forum/topic/1/1

To register for membership visit

http://www.1060.org/forum/join

Security and Privacy:

The application has been written to pay careful attention to security and user privacy.

Your email address is needed to join - a confirmation email will be sent with instructions to complete registration.

Your chosen username is revealed with any posts you make but no other record of your identity is displayed unless you choose to reveal it in your profile.

To enable personal communications to be started outside the forum we provide a mediated email service. This is a trusted broker which you can use to send emails to another member without revealing either your or the recipients email addresses. Once you trust one another you can swap email addresses and talk direct.

Every mediated email provides a link to report abuse of the service - any member that sends spam or abusive messages will be immediately deleted.

Technical:

The forum application runs on NetKernel with a 3-module design, A web-front end controller interacts with a data services module and a separate style module provides for customizable skins.

The web-front end uses an XRL service composition design pattern to invoke "portlet" services (should we call them 'micro-servlets'?) which offers reusable componentised services which are composited to create the application. The result from each service component is cacheable resulting in an fully dynamic app with pseudo-static performance(ie every part of the application is cached to the finest level of granularity).

Application features include: very high performance fine-grained caching of forums and posts, cached RSS 2.0 feeds of both forums and topics, mediated email service to provide communication between forum members without having to divulge email addresses, BBCode entries with dynamic editing and preview, fully skinnable, comprehensive back-end administration tools.

The application took 1 developer week to build the data and web application which included researching and writing the data model. Skinning and presentation took 4 developer days. Total development time, from conception to public site, was just over 1 week.

Release:

The site is now live but not yet linked into our main web sites. With your help we'll take a couple of weeks to shake down the application before linking to our sites and releasing the modules as a 1.0 public distribution for installation to NetKernel.

Please let us know if you have feature requests or find any problems.

We are looking forward to hearing your feedback on the forum...

Menzo has kindly written a case study on the Netherlands Graduate School of Linguistics use of NetKernel...

http://www.1060research.com/buzz/case_tds.html

Thanks Menzo.

The <operand> element of the <instr> in DPML has some interesting characteristics. I find:

* Element body with plain text is interpreted as having "ffcpl:" prepended to the text

* Element body with XML markup is interpreted as an XML document.

This is not what I expected. Would have expected the plain text to be consider the equivalent of the body of an XML element, not a ffcpl: reference. I am not a language design expert(!), but I do find this a bit weird. Or, should I say I do not find this consistent.

Have you had others comment on this facet of DPML? Am I misunderstanding the design intent?

The text value of any element in a DPML instruction (apart from <type>) is always a URI. If you provide a relative URI (ie no scheme) then the URI is resolved against the Current Working URI (this is a concept directly equivalent to Unix's Current Working Directory - this is observered by every NetKernel request (not just in DPML), we discovered we needed to introduce this to make XML pipelines really work).

Like in a Unix shell script, the CWU is generally the same as the script so if you have a script...

ffcpl:/path/myscript.idoc

and relative URI

myResource.xml

This will be resolved to

ffcpl:/path/myResource.xml

In advanced circumstances you can set the CWU (see the NKF API) using any scheme, such as file: http: etc.

Considering the case of your <operand> tag containing an XML fragment (say with with a root <myTag>) then the DPML runtime resolves this to the URI...

ffcpl:/path/myscript.idoc#xpointer(/idoc/instr[x]/operand/myTag)

So a literal fragment gets resolved to a URI reference with XPointer fragment identifier. (Note the accessor that gets called will generally be XPointer aware (at least for the XML suite of tools)). This is very advantageous as the fragment resourse is "pass by reference" and therefore means that the executed service's result can be cached under a key with a dependence on the fragment's URI.

DPML is really a stupidly simple language for expressing active URIs. The first-level tag name of any element within the <instr> block is taken as the argument name in the active URI of a sub-request.

DPML has evolved (I readily admit it is not a perfect language design but it is very simple and easy to use and the exception block concept is pretty powerful). At some point we will produce a v2.0 language spec - we have several ideas to enhance it.

Fortunately, if you need to, it is easy to create a custom workflow language runtime - the custom runtime would take a workflow declaration and issue active URI service invocations.