RE: About XML to multiple language/multiple outputs

Subject: RE: About XML to multiple language/multiple outputs
From: "Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>
Date: Mon, 16 Aug 1999 18:00:20 +0900
First, I should include the usual disclaimer that I don't speak for Next
Solution, etc., etc....

Didier wrote:
> I didn't noticed at first sight, that Frank Christoph was working for Next
> Solutions (provider of DSSSL Print - a commercial product based on DSSSL)
> and that therefore DSSSL-2 could have a lot of impact on
> commercial ventures
> based on DSSSL. This is probably why he expressed some legitimate fear on
> DSSSL-2

Fear? I wanted to know what the scope of the proposed revision was. You are
the one who is soliciting members of this list to participate in the
revision process; at least let us know the rules of the game. If I wanted to
read the ISO handbook on parliamentary procedures I would have become an ISO
member myself.

> (I hope this was the motive and not less noble ones).

I don't know what you're insinuating. What would I gain from undermining
DSSSL-2? (I don't work for Microsoft, after all. :)

That said, the way I started out my post,

Me>That is all well and good, but it seems like you are flying into this
Me>without any sense of purpose besides making something "new."

was a little inflammatory, and I apologize if you took it badly.

Here is the remark of yours which worries me:

Didier Remy wrote on 99/08/13:
> This new draft specification should not be a simple photocopy of DSSSL-1
> but can and preferable should include new improvements and not solely
> minor specifications corrections.

This makes it sound as if you will not be content with a revision unless it
adds some new features. I am not dead set against adding new features, but I
would like to see a rationale for them, and how they sit with the content of
the current standard, as well as some coherence among them. In my opinion,
annexing the XSL standard-to-be is not a good extension because it
duplicates functionality.

It also worries me a great deal when you misinterpret a feature in the
current standard, are corrected by someone on this list, and then propose
your interpretation as an extension to be included in the revision. This
happened when we were discussing the query construction rule. Many people
pointed out the errors in your interpretation(s); then finally you wrote:

Didier Remy wrote on Thu, 15 Jul 1999:
> I agree, but we have to prepare DSSSL-2, do not forget it. And we have
also
> to improve OpenJade and if possible provide powerful new features that
could
> help the community.
...
> So, let's imagine for a moment that we no longer look behind but in front
of
> us and that in front of us there is a new spec to write. let's call it
> DSSSL-2.

It appears, in fact, that the impetus for DSSSL-2 was coincidentally
generated at just this point...

What worries me most is that we are contemplating extensions to DSSSL, but
not only is there still no complete implementation of the thing (e.g., grove
plans and the full page model), and only one widely available partial
implementation (Open-/Jade), but people already complain that DSSSL is too
complex. I think these are quite serious indictments of the usefulness of
the _standard_ (but not of OpenJade).

In view of the above points, I think the focus should be on simplifying,
clarifying and trimming down the standard as much as possible. (However,
adding some small things like "or" rules or Clark's Scheme "import" are
mostly harmless; indeed, they probably add some integrity to the standard.)
If that can't be done as an ISO revision, because it doesn't allow breaking
backwards compatibility, then maybe the best thing is just to let the
standard lapse into oblivion, like the way a good economic policy will let
banks in trouble die off so that they can be replaced by better-managed
banks.

For example, bringing the display model into a closer alignment with that of
CSS and XSL is a good thing, but can it be done in a strictly backwards
compatible way? And, if doing so requires DSSSL to subsume the entire XSL
standard, including the "template" syntax (which you suggested), then is it
really worth the effort?

> First, like Brandon said, do not worry about the ISO process. It is a
> process well organized and nothing will be thrown out without careful
> attention from ISO members. The first step we are taking is to
> aggregate all
> the knowledge we gained in the last 5 years. Also, to aggregate the
> knowledge now found outside of DSSSL and now part of some W3C
> recommendations. All this knowledge is useful and should be
> synthesized, and
> made "explicit" as much as possible in a document.

I'm not worried about the ISO process. But just because there will be a
formal committee considering the issues doesn't mean that we have to sit on
our hands. You want us to participate, right? But when I ask for some
clarifications on what the revision is supposed to accomplish, suddenly you
are threatening to revoke our "privileges," like some angry parent
considering aloud whether he will ground his children:

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

--FC


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


Current Thread