RE: Unregistered flow objects

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Matthias,

Matthias said:
> DSSSL-2 could correct this situation if we include in the specs a
mechanism
> to allow extensions to the basic set ofh objects or more simply, to
include
> as the core set of objects, Flow objects like "element" etc...

How would you do that ? I can't imagine a simple way to tell a dsssl engine
the expected semantics of a nonstandard FO, except by referring to a pubid.
Another (somewhat restricted) way to create new FOs is using a kind of
macro mechanism like the one implemented in James' -2 extensions.

Didier says:
Without being to explicit before I think more on this topic. I'll expose my
thoughts, still immature but let's classify them as "thoughts in progress"
:-)

Actually, with this kind of expansion mechanism (the
declare-flow-object-class ) you can add new flow objects to the core set and
have them switched on or off by a declaration. This mechanism, as you now,
is not part of the spec and is specific to OpenJade/Jade.

As you know, there is at least two possibilities to add new objects to the
existing core set.
a) a library and the new object created with DSSSL constructs (if we imagine
that the expression language could be improved to let you do that - i.e.
that more constructs are added to the core language)
b) A library again but this time created with a different language like for
instance C++

The former is portable from interpreter to interpreter, and you have just to
include the library to your project. The latter is not as portable and
depend on the processor. We have also a gray zone where we can have portable
binaries created in languages like for instance: Java.

By experience we know that the "out of the core set flow objects switches"
declarations are useful only to tell the reader that non standard flow
objects are present in the script and then that only processor able to
interpret these extension will process the script. But it remains that the
script won't work anyway on engines not supporting the extensions. An other
way, is to have no need for any declarations and the engine simply say, at
execution time, that some flow objects are not supported.

Here is the experiment I am doing now to see how we can have a more general
mechanism for expansion.
a) A library declaration. Actually we can include external libraries to our
scripts. I created a library that contains these "declare-flow-object-class"
constructs. These new object are flow objects of a different kind, they are
not visual. They allows us to create as output SGML tags. And therefore
creates the possibility to use SGML or XML based domain languages like for
instance SpeechML or TalkML for aural output. So, I only include an external
library to my scripts and no longer these declarations. And the external
library declaration is, as you know, part of the specs.

But by doing so, I discovered that I created a more uniform universe. For a
script writer, only libraries are present and included in the script in a
standard way. Only the library content is not standard. This can open the
door to libraries that could eventually not be written in DSSSL but in other
languages like for instance C++ (for performance). The library could offer a
set of objects. IN this scenario, We now have a way to expand OpenJade:
through the library mechanism. Also, because libraries are dynamically
loaded, we have now a way to add a new set of functionality without having
to recompile OpenJade.

So, actually, I am probing the code to see how this could be made.

Conclusion: in this model, a library could be a set of flow objects. A flow
object is not necessary a visual object (this is where I think we have
discussion to do for DSSSL-2, expand the notion of flow object to non visual
objects and to state that a flow object is first and foremost a logical
object used to structure the output). Thus, a library could add to OpenJade
a set of aural objects, an other one tactile objects, an other one a XML
based domain language set of objects, etc... The idea being that the unit of
expansion is the library and that the library could encapsulate into a unit:
set of procedures and set of flow objects. A library could be written in any
kind of languages and not necessarily in DSSSL but in an other language like
for instance C++ or Java (with the proper interface to OpenJade)

But like I said Matthias, this thinking in progress....


regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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