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

Subject: RE: Defining widget flow objects (was Re: Interactive XML)
From: JLemire@xxxxxxxxxxxx
Date: Wed, 1 Jul 1998 12:11:08 -0700
exactly!

What the flow objects actually are should be a lot more important to
whatever processes the stream generated by the xsl processing step than to
the xsl processor itself.

If the intended destination of the output stream isn't an HTML rendering
engine....



> -----Original Message-----
> From:	Brandon Ibach [SMTP:bibach@xxxxxxxxxxxxxx]
> Sent:	Wednesday, July 01, 1998 11:42 AM
> To:	xsl-list@xxxxxxxxxxxxxxxx
> Subject:	Re: Defining widget flow objects (was Re: Interactive XML)
> 
> 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


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


Current Thread