Re: (dsssl) The Future of DSSSL

Subject: Re: (dsssl) The Future of DSSSL
From: Trent Shipley <tcshipley@xxxxxxxxxxxxx>
Date: Wed, 9 Jan 2002 00:16:36 -0700
<header>minutes of first week's discussion</>
<header>Part I</>

Since I volunteered to be the secretary and legacy code archaeologist for the 
OpenJade-2.0 (proposed) [hereafter OJ2(P) project I have undertaken to 
summarize and organize the debate from last week's "meeting".

The contents of the debate will be treated as falling into broad categories.
These include project goal(s), philosophy, management issues, proposed 
management requirements, computer sceince and software engineering, proposed 
product requirements, and the inevitable "other" category. 

The most critical problem is the goal remains definition of the general 
mission or goal of OJ2(P).

All are agreed that it would be desirable for someone to do more work on the 
OpenSP-OpenJade toolkit.  Most correspondents seem to favor a significant 
re-architecting of of the underlying software.  In effect, SP and Jade would 
become parts of an modular toolkit known as OpenJade.  The project and the 
Modular OpenJade Object Library target product would effectively merit 
increasing the edition number from 1 to 2 (hence OJ2).

However, some (most importantly Javier) have made statement that could be 
taken as indicating support for evolutionary extension of the current code 
base.  Thus the project would simply finish the work on SP 1.5 and move on to 
OJ 1.4.

There are thus two possible goals:

Extension and Revision (OJ 1.5, synching the release numbers)

Reachitecting (OJ2)

Since Javier will be volunteering the students (presumably the projects 
primary labor resource) he gets to choose whether we pursue one goal, one 
then the next, or both on parallel tracks.



Issues of project philosophy tend to come down to conflicts between the XML 
pragmatists and the SGML purists.  It also tends to be reflected in the 
feature list.  In general, purists want implementation of ISO standards.  
Pragmatists have no objection but tend to add features that would force 
libraries to be highly extensible (eg. So that the SGML parsing engine could 
be extended to handle XML-Schemas).

Proposed philsophical requirements

-- perfection
---- maximum adherence to standards
---- standards implementation
---- CS approach
---- Elegance


--abilty to extend code to accomodate W3C and broadest possible audience 
(Maximum relevance and market appeal.)
-- Max (industrial, commercial) utility.

In additon there is the question of whether this is the appropriate venue to 
discuss the future of SGML, HyTime, and DSSSL standards.

This is a *very* reasonable venue to discuss the ISO markup standards.
The project's working group and groupies will be parties very familliar with 
the standards, their implementation.  Thus, we can and should discuss them 

However, this *does not directly* have any bearing on attempts to implement 
generic, thourough and correct application of the standards in OJ2 or a 
subset of OJ2 as a modular and extensible toolkit.

The real question is should OJ2 aim to implement the DSSSL standards and 
*ONLY* the DSSSL standards or should OJ2 assume that the DSSSL standards can 
be a proper subset (and presumably the default subset) for the OJ2 tool-set. 



 DSSSList info and archive:

Current Thread