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

Brandon Ibach:
>    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.

JLemire@xxxxxxxxxxxx:
> 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.

I'll accept that some extension mechanism for adding
flow objects will be likely.  I don't think we're clever
enough to invent the abstractions that cover every
possible rendering of, or interaction with structured
information.  And, it would be desirable to allow for
small, lightweight XSL processors.

Regardless of which processing step is concerned with
flow objects, though, the person creating style sheets
is very concerned with the behavior of flow objects.  If
she has to resort to proprietary extensions to create
useful user interfaces, than much of the benefit of
using a standard is lost.

The existance of Tk, UIML, Java Swing components, HTML
forms, etc. indicates that powerful, platform
independent abstractions of UIs can be defined.  I would
like to see XSL include in its standard set of flow
objects a model of interactive behaviors sufficient to
build a range of applications without resorting to
extensions or adding the requirement of supporting a
Java VM.

Cheers,

Bill


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