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

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

JLemire@xxxxxxxxxxxx said:
> 
> 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)
> > 
> > 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.
> > 
   If I may step back and provide a little "light" technical
background on DSSSL's processing model here...  The more I look at it,
the more I wonder why we even need to make a distinction between
formatting (or styling) and transformation.  An SGML (or XML) document
gets parsed into a "grove" of "nodes" consisting of a set of
"properties" whose values define that node.  So, each element becomes
a node.  Each element also has a subnode for every attribute that is
defined for it, etc.  It's a very elegant model.  A transformation
will take one or more groves and produce one (actually, potentially
zero) or more nodes, with any possible structure.
   When you get right down to it, a flow object tree, which is the
result of a styling process, is really just another type of grove.  A
flow object becomes a node in this grove, and it's got a whole set of
properties.  The distinction between this process and transformation
*may* happen at the implementation level, but there's little reason
for it to.  Really, the distinction is made at a higher level for the
user's benefit.
   Now, after a transformation has occurred, the resulting grove(s)
needs to get spit back out in some type of format.  The processor
knows how to to deal with nodes of type "element" and "attribute" and
suchlike, and it puts out an SGML (or XML) document.  Similarly, in a
styling process, a format backend (TeX, RTF, etc) will output an
appropriate document based on the resulting tree of flow objects and
their properties.  In this case, the basic processor (such as Jade),
doesn't really know what to do with those flow objects, and it relies
on the format backend to deal with them appropriately.
   As an example, Jade includes an "SGML backend" which allows basic
transformation abilities within DSSSL's style language (due to Jade's
lack of support for DSSSL's transformation language).  This backend
makes use of non-standard flow objects which represent elements,
attributes, entities, entity references, etc.  All you have to do is
tell Jade about these flow objects and the properties they can have
(done using standard DSSSL constructs for this purpose), and Jade will
let you make use of them in the style language.  The SGML backend then
uses those to construct an output document.
   Right now, DSSSL's set of flow objects which are intended to
support online applications doesn't include objects to represent form
fields.  If I were to use Jade as part of a DSSSL-capable browser, I
could declare new flow objects to implement form fields, and when
Jade's DSSSL engine spit out a flow object tree (blissfully ignorant
of what those new flow objects really are), my browser would handle
those objects however I'd like.
   Of course, we wouldn't want every new browser to do their own take
on form field flow objects, because we'd end up with different
versions from everybody.  So, have the W3C standardize aspects of
these flow objects, and let everyone implement them however they want,
so long as stylesheets written to that standard will be rendered
correctly.
   As for the Java VM thing, you certainly wouldn't be *required* to
support one to take advantage of this type of system, but having one
available could allow you to take advantage of custom or new flow
objects dynamically, just as a web browser today doesn't *have* to
support Java to view web pages, but if it does, there are all sorts of
new things you can see.

-Brandon :)


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