RE: About multiple output documents from a single XML/SGML processed document

Subject: RE: About multiple output documents from a single XML/SGML processed document
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Thu, 12 Aug 1999 07:55:07 -0400
Hi Dave,

Dave said:
Yes, that's OK, though I find it less intuitive than
the characteristics we have already.
If the new file naming mechanism works, why not make
use of it, then the characteristic could be from the
familiar,

break-before: 'file

As you describe, but the file name is incremented
as you describe.

Might be simpler?

Didier says:
Thanks Dave for reminding me your suggestion. Having the file name+increment
could be not so bad after all because at least the file is spited into
several output files as with the "scroll" flow object. The problem with this
characteristic is that actually it is a Boolean characteristic as found in
the paragraph FO. This characteristic has the value #t (true) or #f (false).
So, I would have difficulties to include this in the next DSSSL-2
specification drafts. Here are the main constraints we have to face for the
next specifications drafts:

a) as much as possible characteristics has to be consistent (i.e. their
value should be consistent in all objects having the same characteristic)
b) A flow object should be as much as possible independent of the output
media (some restrictions are relaxed for the document model where we have
two different kinds of document model : Simple scrollable page->the scroll
object, and page based (the simple-page-sequence and page-sequence). But in
both document models, the same flow objects could be applied. For instance,
a paragraph object could be used in a scroll document type or in a
simple-page-sequence document type (by document type I mean here the output
document rendition type).
c) New objects or characteristics (i.e. new additions to the existing flow
objects) have to be consistent with existing ones.
d) The overall DSSSL construct has to be at least compliant to the SGML
world (i.e. Hytime, architectures, etc..)
e) we may also be compliant to the XML world. For instance, a DSSSL document
may also be a XML document as long as it can be a SGML document too.

Some other constraints more of political nature :-)

Thanks for contributing Dave, you help a lot for the task of preparing the
DSSSL future (and more particularly the next specification draft).

About the way we can proceed in the OpenJade implementation is that all new
objects or characteristic that could be candidate to the next DSSSL-2 specs
will be available under the -2 option and won't require the external flow
object or characteristic notation. Also, Matthias implemented a new command
line option named "strict" that impose the constraint of using only the
objects contained in the current DSSSL-1 specifications. People needing
"strict" compliance to DSSSL-1 will be served and people wanting to
participate to DSSSL-2 experimentions will be served too.

For DSSSL-2 we have, the great opportunity to base our reasonning on
concrete experience and support our points to the international ISO
community with a solid experimental ground. The task to improve DSSSL-1 is a
collosal job. Here is what's required:

a) Incorporate all specification bug report noticed form the ISO community.
b) Assemble all knowledge we gained about the DSSSL-1 usage and synthethize
this knowledge and make it "explicit" in documents.
c) Assemble comments from the user group and see how their needs could be
satisfied with the constraints previously mentionned
d) Try something rarely done at ISO or even at W3C, start the process from
the user group and work with them the specifications. (we start here a
process a lot more democratic than W3C specs process).
e) Base our reasonning on the resolution of concrete problems like for
example the problem stated by a member of the user group about single
input - multiple output.
f) do what was missing in the DSSSL-1 effort - make documents and document
as much as possible - We have here a real paradox, a document transformation
language used by people involved in documents but no documentation (or very
little) about our tool. This is again the old story about the shoemaker
without shoes :-) I am working hard to correct this (even if my writing
style is not as good as shakespeare :-)
g) and above all, continue with Avi and Matthias (and hopefully Brandon) to
bring new functionalities to OpenJade.

As you see, Dave, the task is huge and the people to do it are very few. But
we are slowly but surely progressing and doing the job that has to be done.
I didn't said that for you Dave, I said all this for the user group so that
the group can take for a moment notice of all the task we have to do and
that we all do that on a volontary base, just for the love and passion to
nurture a language and environement we learned to appreciate.

Thanks Dave for you idea, keep thinking and continue to bring new ideas. The
OpenJade team appreciate your input.

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


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


Current Thread