RE: About XML to multiple language/multiple outputs

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

Hi Frank,

Frank said:
That is all well and good, but it seems like you are flying into this
without any sense of purpose besides making something "new." Fixing
inconsistencies and errors in the standard are obviously things one wants to
accomplish in a revision.

Didier says:

OK, I could ask you to spell the word assume but I will simply answer. Read
carefully this message...
a) yes there is obviously error correction for the next draft
b) proposal to modify certain flow objects to add new characteristics to
harmonize with online medias and with XSL, CSS

extract from a previous message to this list:
-----------------------------------------------
As complementary information about CSS, XSL and DSSSL (the XSL section still
very incomplete)
ref CSS: http://www.netfolder.com/CSS/CSSObjects.htm
ref XSL: http://www.netfolder.com/XSL/XslFo.htm
ref DSSSL: http://www.netfolder.com/DSSSL/Paragraph.htm

So if we take, for instance, the paragraph object, its equivalency in the
XSL and CSS worlds is the block object. You'll notice that in the last
document (i.e. DSSSL paragraph) a reference is made to the CSS:block and
XSL:block objects. This is because these objects are similar. Basically,
what James proposed is to add new characteristics to unify the CSS and DSSSL
world. Since then, XSL evolved and discussion occurring in the XSL
discussion groups and WG added pressure to unify the basic visual models of
CSS and XSL. XSL flow objects, however,  are still inspired from DSSSL and
provide more characteristics than CSS. This may not be the case forever.
Actually, the XSL flow object set is more complete than the CSS object set.
Some of James suggestions have to be modernized and we need to include the
latest knowledge we gained from all these discussions, specifications,
implementations (the document is a 1997 document and we are in 1999).
However, the proposal has the virtue to add more capabilities in the on-line
world and expend some objects, like for instance the scroll and paragraph
objects with new characteristics like :
background-color
background-image
etc....
And this is still pertinent to the actual realities. James document is one
important base to the document I'll publish about DSSSL-2 possible
orientations (but modernized with the knowledge we gained since the last two
years).
--------------------------------------------

c) also possibility to add new ways to express templates as found in XSL but
with DSSSL constructs

extract from a previous message to this list:
-----------------------------------------------
a) transformation based on templates (suggested by some members of this list
as a way to resolve some problems and this do not replace the transformation
part of DSSSL-1, just complements it)
-------------------------------------------

d) add new functionality like the possibility to do not only document
aggregation but also creation of multiple documents form a single input

extract from a previous message to this list:
-----------------------------------------------
b) multiple input/single output (we get that), single input/multiple output
(we do not get that for page oriented rendition). Also, the notion of output
document has been left out of DSSSL-1, DSSSL-2 could provide more guidelines
(for instance, in one case, a scroll object is associated to a file and in
one case the simple-page-sequence is associated to a page context- this kind
of ambiguities could be resolved by guidelines or notes added to the specs
or by new constructs).
--------------------------------------------

Is this more than simply fixing specifications errors?

Now, the next item...

Frank said:
But what are the other things that are up for
grabs? For example, are we allowed to break backward compatibility? To what
degree? Are we allowed to delete things from the standard? Are extensions
acceptable? What must be preserved?

Didier says:
If some demonstration is made that a previous item in the specification is
really bogus (demonstrated by concrete experimentations) this item could be
removed. We cannot break backward compatibility. Extensions are obviously
acceptable and new items could be added. A specification is a living thing
it can evolve with its time. This is why ISO standards like the DSSSL one
are renewed after 5 years. These five years are not dominated by emptiness
but with experience gained with implementations based on the previous
specifications. From this experience, and from needs not fully addressed or
badly addressed by the previous specifications, some items could be either
deleted (not encouraged) modified (as long as backward compatibility is
preserved) or expanded (new objects, features, characteristics (encouraged).

The transformation part of the DSSSL-1 specifications was never implemented.
We cannot say that this part is not useful nor say that this does not work
properly. Therefore, even if it where never implemented, it could (if
Brandon make it - Brandon, we need you there :-). So, this part being not
demonstrated as bogus should be kept. Some may not like the syntax being
scheme based, but this cannot be demonstrated also that this syntax is
bogus. This is also kept. So, the actual spec could be kept, and bugs in the
text corrected. However, we can improve by adding new features. or expanding
the already existing features.

Some flow objects needs some additional characteristics to offer more
functionality

extract from a previous message to this list:
-----------------------------------------------
However, the proposal has the virtue to add more capabilities in the on-line
world and expend some objects, like for instance the scroll and paragraph
objects with new characteristics like :
background-color
background-image
etc....
----------------------------------------------

A new section based on templates could be added to the specifications. The
section could (I do not say will) be named "template-specification" and
itself contains a declarations element and a "template-specification-body"
(there is a high probability that the declarations are to be superfluous and
then only the element "template-specification" would be needed). As an
example of a template specification:

<template-specification>
<HTML>
<TITLE><dsssl:query (title:child(data))></TITLE>
</HTML>
</template-specification>

Note: i do not say that the construct would necessarily as stated in the
template. This is provided only as an example not as a final direction.

This new section would require from us to improve the query-expression.
James made the suggestion of a query language (at that time it was not so
clear, today we would say it was the first step toward XPath) for
element-match. Ken Holman, made the suggestion of a Query language based on
a simplified query language able to acces any element in the grove. So here,
an other area of improvement. We may keep the actual
query-expression-language also shared by Hytime (v 2.0) but could add new
simplified constructs allowing not only rule based (push model) but also
templates as above (pull model). This could leads to simplified
implementation of rules like the rule "query". Also a flow object could be
created as a template and referred with a procedure within a rule.

<template-specification>
<dsssl:flow-object id="div">
<DIV style=(characteristic("style"))>
hello the people of this world
</DIV>
</template-specification>

<style-specification>
.....
(element item
	(make div
		style: "etc....")
	)
)
</style-specification>

Note: the example above is stated only as a suggestion or as a first step
for further reflection not as a final direction.

The first task as stated previously is to first sort this, collect the
people's needs: unfulfilled needs and needs fulfilled with high costs. See
if some of the previously stated solution may provide an adequate solution
to these problems and then prepare a first draft. We are now at the probing
stage. It is open to suggestions and comments from people. However comments
like:
it seems like you are flying into this "without any sense of purpose besides
making something "new."
Could make me regret having chosen an open dialog with the DSSSL community.
I could have chosen to prepare the draft behind closed doors without any
previous consultation from the user community. However, what is reassuring
is that a lot of people instead feed the process by expressing unfulfilled
needs and making constructive comments and suggestions to the table. I hope
Frank, that you'll go from this kind of comment to useful contribution by
helping us compose a better draft. Then, we'll work hard to carry this draft
to a formal specification and then bring this latter toward acceptance from
the ISO community.

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


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