Re: Defining widget flow objects (was Re: Interactive XML)

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Bill Lindsey said:
> 
> David vun Kannon (dvunkannon@xxxxxxxx) wrote:
> 
> >         However, I think the whole discussion of what is, in
> > effect, UIML, is somewhat inappropriate to this list. We don't
> > need this or any other random set of flow objects rammed into any
> > particular rev of the XSL spec.  We need a general way to declare
> > which flow objects the style sheet is using and where to acquire a
> > rendering engine for that set. Then the W3C will be out of the
> > flow object business except for the case of HTML, which is a
> > standard it owns. Then Adobe can sell a package of PGML flow
> > objects and a style sheet can turn database output into
> > hyperlinked infographics, and the milling machine industry
> > consortium that defines Numeric Controller ML can rest easy,
> > knowing that the software suppliers that support that industry
> > will implement the flow object library that will allow database
> > output to be rendered as milled metal, XML document to engine
> > block via a style sheet.
> 
> Interesting idea, but don't think I agree.  You seem to be
> saying that specifying the semantics of flow objects should
> not be part of the XSL mandate. Or, should it just be limited
> to two dimensional formatting flow objects?   
> 
> I would think that the specification of the behavior of 
> flow objects is precisely the value of XSL.  That's how
> we get inter-operability. If I have to write separate 
> stylesheets for Netscape flow objects, and Microsoft 
> flow objects, what's the point of using XSL? I might just
> as well use their proprietary, optimized 
> XML styling languages.  
> 
   Actually, these two points are not incompatible.  The DSSSL
standard does actually seperate the overall language from the flow
objects, then supplies standards for core flow objects (which a
minimal DSSSL implementation should supply, even if it doesn't support
all of the characteristics for each one) as well as some other
recommended objects.  It also provides some mechanism for declaring
your own flow objects (though I'm not quite sure just how that would
work in practice).
   So, couldn't the XSL spec provide some well-defined mechanisms for
declaring flow objects (and sets thereof), then define some standard
sets of them which the vendors can provide implementations of?  That
way, your stylesheet can always rely on the "basic XSL standard online
flow object set", which will always support the standard
functionality, but may also include some vendor-specific extensions
which your stylesheet could detect and take advantage of, at its
option.
   In addition, vendors could support flow object sets that are
completely seperate from the standard, and provide different types of
functionality.  These could possibly even be provided as Java classes
that hook into an XSL engine, so that the browser could pull them down
as needed.

-Brandon :)


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list