RE: The DSSSList Digest V3 #106

[MARK.WROTH@xxxxxxxxxxx (Wroth, Mark)]

Mark here, responding to Didier's response to my comments on SENG (or more
accurately, what characteristics might induce me to switch from Jade to
another DSSSL processor)

(I) Mark said:
	2.  I might be persuaded to switch by implementation of more of the
query and transformation languages.  I say "might" because I can do
everything I need to *at the moment*, but would prefer to do so within the
[...]

Didier says:
We are working hard to add these capabilities. To improve and innovate (for
DSSSL-2). To document the OpenJade internals to better understand its
structure for maintenance and new feature addition. We're not yet in the
transform part but a piece at a time....

Mark replies:
	I understand, and am glad to hear it.


Mark said:
In general, of course, if SENG were "better, faster, cheaper" than Jade, I
might be inclined to switch.  But I think the areas I describe above are the
main things that would make me consider adding/switching to SENG.

Didier says:
If SENG has all the transformation and style part of DSSSL implemented, is
faster than openJade (I have serious doubts about this), and obviously not
cheaper (cannot be cheaper than free except if we get money for using it :-)
then, I say, its a shame that SENG is not out there is the hands of users.
But if it provides only a tiny fraction of what OpenJade provides now, then,
I would say that it could take a long time before SENG could equal OPenJade.

Mark replies:
	I wasn't asserting that SENG was any any of those things; just that
I have a generic interest in improved processing.  "Better, faster, cheaper"
has become something of a catch phrase in my general area for improved
processing....

And now for the real subject:

Mark said:
(BTW, my primary applications are paper output based, with concurrent web
publication. They involve processing documents through several stages of
aggregation and commentary, and have the potential to grow to a research
database.  So I care about the style, query, and transformation aspects of
SGML/XML manipulation, with varying emphasis depending on the moment.  Right
now, the group I'm working with is implementing a multiple document "merge"
process in Java, partially because I don't see an easy way to do it in
DSSSL. )

Didier Says:
Mark this is an interest point. I am actually studying this part of OpenJade
(and documenting it too). Can you tell us more about what you are trying to
achieve, this will help a lot our quest to improve OpenJade either through
documentation or code. So, If you just provide us with more info, we may
either bring new constructs or document ways to do it. have you tried the
sgml-parse and (process-node-list) construct to achieve what you want? if
yes what where the limitation you encountered that let you to use Java
instead?

Mark replies:
	Generally, what's going on is an attempt to add SGML/XML
functionality to an existing paper/electronic system in which specific items
are proposed, commented on, and passed on , through several levels of
aggregation, until they are finally decided, published, and recorded.

	The  process starts with an individual request, possibly with
attached justification. 

	These requests are aggregated (in the sense that a document
containing all of the requests is created) and a first level decision on
each request is made to either return (refuse) the request or forward it to
the next level. As part of this decision process, comments and justification
may be attached to each item. A report is prepared, listing all of the
requests made, by area, the discussion/justification and reasons for the
disposition of the request, and the actual disposition of each. A second
document (called a "LoI", for Letter of Intent) is prepared, listing all
requests being forwarded to the next level with justification; this is the
input to the next stage of processing.

	Various other individuals are invited to comment on the specific
items proposed.  They provide documents which list their comments on
specific requests, usually including  several LoIs worth of requests.

	Optionally, this process may be repeated at a second level of
decision/aggregation.

	Eventually, the request packages reach the final decision level.  At
this point a decision package is prepared, which organizes all of the
requests to be acted on by region.  Each item is presented with all of the
commentary/justification; specifically, the basic request, with its
supporting justification is merged with any commentary received (think of a
content model like (request, comment*) ).  When this decision package is
acted on, a decision, and possibly discussion, is added to the item
(request, comment*, decision, discussion?).

	This decision information is then published in both print and web
versions (with the original request and commentary omitted), and archived.
Some of the decisions (the ones which are approved) are then transmitted to
another processing center, where information on the decisions is added to a
(fairly large) database.


We are in the process of implementing an XML version of processing at the
top level decision node -- I've already implemented an SGML-based system at
one of the subordinate nodes.  This is being done in conjunction with
another set of changes at the top level, and so is being partially driven by
schedule concerns rather than technical concerns.  
	
	Many of the input documents to this top level are being processed
into XML by automatic parsers written in Java.  As a division of labor, the
person writing these parsers is implementing a merge processor; it was not
immediately obvious to me how to do it in DSSSL, she knew how to solve the
problem in Java, and I needed to be writing the output scripts, so the merge
processing is being done in Java and the output scripts are in DSSSL.

	Eventually, we will want (I think) an ability to post-process all of
the archived decision documents for various forms of research.  But that's a
future topic... :-)


If we want to go into more detail, I'd be happy to have help.  At some
point, though, the discussion is going to be too specific for this list (if
it isn't already :-), and we would need to go offline.


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