RE: About the declare-flow-object-class

Subject: RE: About the declare-flow-object-class
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 06 Jul 1999 07:50:39 -0700
At 99/07/04 20:19 -0400, Didier PH Martin wrote:
>I do not mean in the actual Jade implementation which is like you said. I am
>trying to find the intent of the editors that just said very little about
>this construct. Actually, you are right, they do not specify that the
>implementation to be in a DSSSL script but it may be in a script or in
>whatever the implementer decides.

Precisely.  In my experience, the ISO specifications I've worked with
provide for the identification of extensions but typically not the
implementation techniques of such extensions.

>I think that we need to clarify the expansion mechanism for DSSSL-2.
>actually, it is not clear enough.

I disagree ... I think the right balance is already struck in the DSSSL
standard.

The ease of implementation of extensions is an opportunity for product
differentiation between vendors.  Mandating extension mechanisms may limit
flexibility or innovation.

The current use of an FPI will guarantee unique *identification* of
extensions, but a given implementation platform will provide specific
implementation approaches.

>I'll start a discussion thread specific to expansion mechansim. My own
>opinion is that the library is a better tool for this and it also provide a
>package for any expansions. 

Certainly as a feature of OpenJade, but not IMNSHO as an aspect of DSSSL-2.

>Also, if we specify that a library could be made
>in any language as long as a set of procedure and flow objects are exported,
>we increase the versatility and also simplify the expansion mechsnaism to a
>single entity. We would then have to manage libraries and libraries would
>contain different implementations.

Within OpenJade, yes.

Finding the balance between what is mandated vs. what is available to the
implementor to implement is difficult.  I've often felt that what I've
learned in the DSSSL-1 example is representative of accepted practice in
ISO standardization.

I hope this input is considered useful.

.......... Ken

p.s. Didier, your computer clock appears to be set incorrectly; your
message seems to be timestamped before the responses to which it refers.


--
G. Ken Holman                    mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/d/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Website:  XSL/XML/DSSSL/SGML services, training, libraries, products.
Publications:   Introduction to XSLT (3rd Edition) ISBN 1-894049-00-4
Next instructor-led training:   MS'99 1999-08-16  MT'99 1999-12-05/06


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


Current Thread