Re: A few question about SENG/DSSSL environment

[lex@xxxxxxxxxxxxxx (Alex Milowski)]

> it seems that almost all discussion in this list turns around the 
> Jade DSSSL implementation (it is really a great work). Nevertheless,
> does anybody have any experience with the Java-based SENG/DSSSL 
> environment?

Well, with the exception of a few, the answer will be "no".  Seng has
*not* been release except to a few individuals and companies.

> I tried working with SENG and I found interesting that it should
> contain "the infrastructure for `loadable' flow object semantics"
> (according to the dsssl.flowobject package overview). I tried to 
> find out how this works from short descriptions of classes and 
> methods available but there are still some points I do not understand:
> 
> 1. If I define a new flow object class in a DSSSL specification,
>    for example:
>    
>    (declare-flow-object-class myclass "-//cz.myorg//DOCUMENT myclass//EN")
>    
>    how it is processed? Does dsssl.engine.Processor object read any
>    specification of flow object class semantics from the referred external 
>    entity? If yes, what should be the format of this specification?

No, it does not read an external entity.  Seng works on the concept
of a "Flow Object Registry".  The Flow Object Registry is responsible for
locating, from the public identifier, an instance of FlowObjectDefinition.

Currently, in the default Seng environment, there is a class called
LoadingRegistry implemented very simply as follows:

public class LoadingRegistry extends Registry {

   Vector packages;
   ClassLoader loader;

   public LoadingRegistry(ClassLoader l) {
      packages = new Vector();
      loader = l;
   }

   public void addPackage(String pname) {
      packages.addElement(pname);
   }

   public void removePackage(String pname) {
      packages.removeElement(pname);
   }

   public FlowObjectDefinition lookup(compname name) {
      return lookup(name.appnm);
   }

   public FlowObjectDefinition lookup(String name)
   {
      FlowObjectDefinition def = super.lookup(name);
      if (def==null) {
         int psize = packages.size();
         String cname = name.replace('-','_');
         for (int t=0; t<psize; t++) {
            try {
               Class defclass = loader.loadClass(
                  ((String)packages.elementAt(t))+"."+cname
               );
               return (FlowObjectDefinition)defclass.newInstance();
            } catch (ClassNotFoundException e) {
            } catch (IllegalAccessException e) {
            } catch (InstantiationException e) {
            }
         }
      }
      return def;
   }

}

This class extends Registry with is an implementation of the 
dsssl.flowobject.Registry interface.  In this example, the LoadingRegistry
class will load the FlowObjectDefinition class from the class loader
specified.  If this were an applet, it would come from the 
web server the applet came from.

Several weeks ago I sent James Clark a very short message about the idea
of a way of specifying flow object definitions in Scheme.  This would 
allow us to share custom flow object definitions between Seng and Jade.

I'm afraid neither of us has spent much time hashing out *if* this is a good
idea and what the *exact* syntax should be.

> 2. Interpretation of flow objects on different presentational media is
>    probably implemented in different subclasses of dsssl.flowobject.Exterior
>    class (e.g., COM.copsol.dsssl.exterior.AWTExterior class). How can
>    these classes (especially the atomic method) cope with instances of new 
>    application flow object classes? Can they use any specification of flow 
>    object class semantics?

Unlike Jade, Seng builds a real flow object tree (I'm not criticizing Jade, this
is just a design decision).  The flow object tree is a "node-property-bag" and 
tree data structure.  Once you have the tree, you can dynamically load any 
dsssl.flowobject.Exterior compliant class and apply the exterior to do 
whatever you want with the flow object tree.

Instances of flowobject--custom or standard--are accessed through the
ported, atomic, and node interfaces of the dsssl.flowobject package.  At this
point in time, it is up to the exterior to have intimate knowledge of how
to handle a custom flow object.

On the other hand, we have been tossing around a design for a concept
called interiors in which semantics for custom flowobjects can be loaded
dynamically and independent of each other.  For example, an AWT interior
could load the semantic for a custom flowobject that is has no knowledge
of from the server the document came from.  

This concept/feature is not in the current version of Seng.

> So far, only part of SENG/DSSSL environment implementation is available,
> the rest are only Java interfaces, but I think that its architecture
> is interesting and I would like to hear from someone who also tried
> to investigate the parts already available.

Almost all of the DSSSL Developer's Toolkit is implemented.  We are in a 
stage of validating the DSSSL engine, SDQL, and the Style Language.  In addition,
we are developing some basic exteriors such that you can do something
practical with Seng--actually produce documents you can print.

Although we have good support for the Style Language, we are also working
on the transformation language and complete SDQL support.  Seng is also
a Scheme environment with DSSSL primitives.  This means that you can
write Scheme programs that use SDQL and the like.

Every available from Scheme is also available from Java.  Hence, you can write
Java programs that can use SDQL and the like.

Seng will be available by the SGML/XML '97 conference.  We expect a beta version
before that but have not set a date.
 
==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@xxxxxxxxxx
Copernican Solutions Incorporated                  (612) 379 - 3608

 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist