RE: The DSSSList Digest V3 #105

Subject: RE: The DSSSList Digest V3 #105
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Thu, 15 Jul 1999 11:29:22 -0400
Hi Mark,

Mark said:
I see two reasons why I would care:

	1.  A Java based DSSSL processor would make it easier for me to
proliferate the different SGML/XML applications I'm involved with to more
people/platforms.  The Mac is my specific concern, since I don't know of a
Jade build for the Mac (and I'm not in a position to either build one or ask
the people I'm trying to interest in the system to build one).  For this
purpose, implementing at least those portions of the DSSSL standard
implemented by Jade would be desirable/necessary.  It would be even better
if the Java DSSSL processor dealt with everything Jade does (specifically
including the non-standard SGML output sosofos).

Didier Says:
Yes, we do not have a mac version and this is lacking. If only someone with
a mac compiler would be helpful enough to compile OpenJade with let's say
CodeWarrior, we would have a mac version. But yes, the actual state is that
the mac platform is absent in the OpenJade world.


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
*standard*, so that I don't tie my users to a specific implementation (in
other words, Jade does the job, at least for now, but I'm not happy that I
have to use non-standard features to do it because I'd rather not build a
system which depends on one implementation).  I _suspect_ that as my
applications grow (if they do), better query capabilities (than currently in
Jade) will be desirable --- but I'll caveat that by admitting that I'm not
even close to understanding all that can be done within Jade's existing
implementation.

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 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 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?

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


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


Current Thread