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

[JLemire@xxxxxxxxxxxx]

I would like to see XSL avoid getting bogged down in all that entirely add
just semi opaquely pass whatever the style sheet author puts in the action
through to the output stream and let the next cog in the machine do what it
knows to do with it.  That way there needs be no reving of XSL or HTML or
any other recommendations to keep sets of flow objects in sync...

let it:
	have a simple dtd,
	lose HTML
	define the pattern specification and matching rules,
	provide "attribute" rules and merging capabilities (making no
special case of "style")
	provide a simple object model (and keep the ro access to the core
XML om)
	keep the escape to script with lang attribute on xsl script tags
(default ECMAScript)

Processors wouldn't have to know about differing sets of flow objects, core
or otherwise and xsl wouldn't need to manage rev's to the core set.
Processor vendors could compete on sets of (script) languages supported,
size, speed, and efficiency instead.  Id rather see most of the "new" and
"interactive" come from css adopting "behavior"

> -----Original Message-----
> From:	Bill Lindsey [SMTP:blindsey@xxxxxxxxxxx]
> Sent:	Wednesday, July 01, 1998 7:58 AM
> To:	xsl-list@xxxxxxxxxxxxxxxx
> Subject:	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


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