RE: About the declare-flow-object-class

Subject: RE: About the declare-flow-object-class
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sun, 4 Jul 1999 18:57:37 -0400
Hi Avi,

Avi said:
1. A flow object name (symbol) cannot be guaranteed to be unique, but a
public identifier ought to be.
2. A public identifer allows specification of additional information via an
external mechanism (for example, the name of the library implementing the
flow object)
3. Consistency - anything external or extensible is defined via a public
identifier (color spaces, for example)

Didier says:
At first sight, when I tried to understand what the FPI is used for, I
thought that its usage is the same as for a XML name space. Said
differently, that its main purpose is to uniquely identify an extension.
This, mainly because two different flow objects could be included with the
same name. However, this, practically do not work (without a namespace
mechanism). So, the point 1 cannot practically work. Point 2 and 3 are more
plausible. Now the problem is: was the spirit of this declaration to be like
the color construct or that a flow object particular to an application could
be located in a different place. So to speak, if the FPI main purpose for
the "declare-flow-object-class" is to locate the code or to serve as a
unique identifier to keep consistency with constructs like color.
I know that generally FPI are used for different purpose but in the case of
this particular construct, I am not so sure it is used with a location
purpose. Or if it is, this would means that a custom flow object reference
could point to a particular location within a DSSSL script. Then, the
question, in that case, would become, with what kind of linking mechanism
(hytime?, IDREF?)

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


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


Current Thread