Re: Unregistered flow objects

[Matthias Clasen <clasen@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

> Didier Says:
> Darell you touched something fundamental here. James wanted to distinguish
> what's part of the official DSSSL specs and what is an extension that is not
> part of the specification. This is why you have these annoying declarations.
> This is a mechanism James found to tell an eventual alternative DSSSL
> processor that this is an extension. However, the script would not work on
> this alternative processor because it would not support these extensions.
> There is actually a hole in DSSSL about the extension mechanism and ways to
> use new domain languages based on XML.
> 
> DSSSL-2 could correct this situation if we include in the specs a mechanism
> to allow extensions to the basic set ofh objects or more simply, to include
> as the core set of objects, Flow objects like "element" etc...

How would you do that ? I can't imagine a simple way to tell a dsssl engine
the expected semantics of a nonstandard FO, except by referring to a pubid.
Another (somewhat restricted) way to create new FOs is using a kind of
macro mechanism like the one implemented in James' -2 extensions.  

On "element" and friends: While using the same syntax for transformations
and formatting may make it easier to use and implement, it is a bit ugly
that "transformation FOs" break the explicit semantics assigned to FOs
(a FO specifies a couple of areas - transformation FOs don't). 

On declare-flow-object-class: Isn't there a flaw in jade in that 
declare-flow-object-class isn't a standard procedure, yet doesn't have
to be declared via external-procedure ?

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: clasen@xxxxxxxxxxxxxxxxxxxxxxxxxx
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg


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