RE: Groves processing in OpenJade

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

Hi Matthias,

Didier said: (Note this extract is without its context)
-------------------------------------------------------
> B) A grove plan based implementation requires a dynamic structure

Matthias said:
-------------------------------------------------------
No. Why do you think so ?

Didier says:
-------------------------------------------------------
You are right on the first point. A grove plan (like specified in DSSSL-1
specifications) do not require a dynamic structure. Thanx for the question
"Why do you think so" which is usually a door opened to constructive dialog.

A) the actual DSSSL-1 specifications tells that only the grove plan modules
have to be included in the sgml-grove-plan section (i.e. element). The
following modules (defining the SGML grove plan) are included by default, so
there is no needs to declare them:
? baseabs
? prlgabs0
? instabs
If the interpreter is aware of other modules like, for instance, some Hytime
modules, then, these modules could be added to the default ones. This is
done through the "modadd" attribute. as in the example below:
<sgml-grove-plan modadd="Hylink">.

Actually, Hytime adds to the basic SGML document model (i.e. grove plan
modules) some of its own, allowing to now to use groves in an hyperdocument
(or linkage) perspective. Thus, because both Hytime and DSSSL uses SDQL as
query language, then we can do (if the Hytime modules are included in the
grove plan) queries on element as Hytime elements with Hytime properties.

Thus, if we declared, in the sgml-grove-plan, that we also include the
Hytime modules to the basic sgml modules then, the grove nodes are now, not
only conformant to the sgml property sets but also to the Hytime property
sets. We can get, not only sgml properties (from the sgml property set), but
also Hytime properties (from the Hytime property set). If, for instance, the
topic maps specifications where to have their own property sets, and that
the interpreter would support the topic map module, then each grove's node
would be perceived as a topic node and would therefore have topic's
properties. And so on...

B) The actual OpenJade implementation, which for speed reasons (I guess this
was the main reason) has all the grove elements defined as structures (or as
classes) do not need to parse property sets to build the class superclass
structure. The property set knowledge is then hard coded in these structure.
This implies that to add a new property set is to modify the structures
(classes) so that the new node types and their respective property
collection are added. For instance, because most of Hytime classes inherits
from the sgml property set, this implies that, Hytime elements are also sgml
elements (because of the class inheritance). Thus, to support both the
Hytime and the sgml property set, the structure (class) as to be modified to
include the Hytime properties in  addition of the sgml properties. This has
the major advantage of speed during the document processing, this has also
the drawbacks that each time we want to add a new property set, code has to
be modified, compiled. But this solution has the virtue of being fast during
the script execution phase (not a negligible feature).

C) a very versatile grove engine would allow to dynamically include property
sets without having to modify the application. Property sets are defined
with sgml based documents. Classes, super classes, and associated properties
could be included in the application with a sgml document providing the
property set definition. For example, let's imagine that we include the
Hytime property sets in the code. If the ISO topic map group where to come
with a property set, we would have to modify the code to include the new
property set. If, ad contrario, the application would be able to interpret
property set documents, we could include the new property set without having
to recompile the interpreter. There is, however, a drawback, processing
speed. Because, even in the best case, a new file need to be read each time
a document is processed (I do not say here that this file contains property
set in sgml format - the file may in fact contains a compiled version of the
property sets). There is, however, a possible solution to prevent a file
load at each document processing.

D) In both Hytime and DSSSL the notion of property set is, in a certain way,
a static one. It is very hard to add semantics to the queries ( a la SDQL).
To be more precise, it is hard to add domain specific semantics (i.e. to
allow the definition of property set for a particular domain) DSSSL-2 could
be an opportunity to improve the property set model so that, elements could
be related to classes. If, for instance, we create a property set with a
class, legal-document, then relate this class to a super class,
sgml-document, and if finally, we relate the class legal-document to the
element <legal>, we create a dynamic model where now the property set
includes: classes, super classes and instances. This implies that, all
<legal> elements are legal-document and therefore sgml-document instances. A
query could be based on the legal-document properties that are more
pertinent to the domain than are sgml properties which are of more general
purpose. Both Hytime and DSSSL could benefit with this new improved property
set mechanism. To implement such model, a completely dynamic grove class,
super class, instance definition is needed. I know that this last concept
may not be easy to grasp (based on the answer form the previous message) but
with close attention it may be understood. So, read carefully this
paragraph, because this is one of the major reason why a dynamic grove
definition may be necessary. If however, the explanations are not clear
enough, a document will be published with more reference and text to explain
it. This document, I hope, should facilitate the understanding of this new
concept. Until then, I'll be glad to discuss it, as long as the dialog is
fruitful.


Didier said:
--------------------------------------
> b) The grove element static structure needs to be replaced by a dynamic
> structure where classes inserted in the dynamic structure are defined in
the
> grove plan.

Matthias said:
--------------------------------------
No, we need to change the order of spec parsing and grove building.
Then we can pass a list of grove plan modules to be included to the
grove builder.

Didier says:
--------------------------------------
Exactly, I agree on the sequence order. Obviously - we'll need to also
implement some change in the code so that now, we would support all Hytime
property sets (if this is the goal). This, obviously implies that some
OpenJade structures (classes) are modified. Then, when the ISO topic map
group will come up with topic map property sets, we'll have again to modify
the code. Then, if the ISO ISMID group adds new property sets, we'll have
again to modify the code. If the ISO HTML group come up with a property set,
we'll have again to modify the code, etc... Obviously, we do not need to
implement a dynamic definition, but there is some consequences.

 Like I said earlier, static definitions lead to fast processing. However,
this could be resolved by storing the compile property set in one of the
code segment (at least in windows, but I am sure that Linux binaries have
also this kind of capability). Off course, there is also, a question of the
amount of work involved. These are clear implementation tread off - not
design issues. But these issues are different issues that are based mainly
on time and resource constraints. Arguments to which I am very sensible .
Was I clear? Is some more explanations necessary?

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


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