Re: Defining widget flow objects (was Re: Interactive XML)
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format