[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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 15:03:43 -0700
defining widget
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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.