[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] XSL/XML/XLL and VRML (was: Re: Conditional actions in XSL?)
>W. Eliot Kimber wrote: > > If the style is re-applied as quickly as possible, then I > have what appears to be an "interactive" document (when what I really have > is a very responsive presentation system). > > Clearly you could model everything that user interface systems like VB and > PowerBuilder do using this approach, although I don't know if it would > provide any benefits (it might, who knows?). It does. It can do what DTDs do well: provide a precise description of the presentation style of the interface as a set of routed behaviors. Behaviors can be scripted or compiled, inlined or referenced. The best part is that at the authoring interface, the author sees the objects and simply connects them. Properties are initialized in dialogs, and voila, a Rapid IDE based on XML emerges. I was just looking at http://www.cam.org/~pierlou/prototype/ and Pierre Morrel's Prototype approach is wonderfully direct and easy to work with as a document or in created an authoring system for it. HTML is another example in how forms are done. The MID was built along the same design principles. > Of course, how much > difference is there between interpreting VB code and applying style sheets > like the above in a tight processing loop? None, I would think, except that > the grove-based approach may have an additional layer of abstraction that > either makes new things possible or slows the system down to unacceptable > levels (or both). Is that layer of abstraction necessary in a system where the XML/SGML is used primarily for properties and relationships among properties and Java is used for implementation? I look at the design of VRML by comparison (if this is screwed up, Chris Marin, feel free to pummel). It is a scene description abstraction for animating a 3D space of presentation objects and property engines. The engines that animate are timer-based. For example, a TouchSensor object (interface for mouse or what have you) emits a touchTime value to a TimerSensor object. The TimerSensor emits time values changes to a function in a presentation object (eg a Transform that contains a box primitive) which sets the value of a translation or rotation property and any children of the Transform node are rotated or moved in 3D space. A tree of transforms (group nodes really, but the tranforms are the heart of the system) is hierachically organized so that the state space reflects the spatial organization of presentation objects. That is, the transforms nest such that what is done to a parent is done to the child. Events are organized by routing among the named objects, eg, TitleTimer and Box. ROUTE BoxTimer.fraction_changed TO BoxPostitionInterpolator.set_fraction ROUTE BoxPositionInterpolator.value_changed TO Box.set_translation So statically: NamedTimer(eventOut) -> NamedPresentationType(eventIn) NamedPresentationType(eventOut) -> NamedPresentationObject(EventIn). Note the paired statements for completing a route. What would be the restatement of this relationship in an independent link? Presentations are typed. Eg, PositionInterpolator to translate, OrientationInterpolator to rotate, and so on. Values passed among the objects are typed (eg, SFFloat) and must match when routed, but this is prototyped in the object specification (eg, the VRML standard or a proto). I suppose one could use architectural forms to model this. The actual presentation engine is a method of the presentation processor. What the author is actually creating is a set of time cycle properties (fractions of the cycle)routed to a set of key frame properties (literally, positions in vector space in the example) which are then routed to the Transform properties. Moving the space moves the object in the space (eg, the box). The box as a geometric object has properties which can also be changed by routing (eg, changing color properties by routing a property set of floating point typed values, etc.). So, I *think* creating a VRML grove description is straightforward but I haven't tried so the jury is out on that. EventIn and EventOut properties have explicit directional definitions defined on the object/node in the tree. It is the object that knows how it behaves, not the link. The link or route statement connects functions to properties to organize state changes of the presentation objects. Behaviors are organized by route statements instead of function calls. In one sense, it is a syntax cheat because it is still a value/function statement, but in a practical sense it is easy to author and easy to use when extensible objects are added. Protos and external protos are used to extend the language. The application language (VRML97) provides the common format, and the implementation language/object_framework provides the inteoperability of new objects by which the language is extended. Once an object is added, it only needs to be routed. If processing of event values is required enroute, it is routed through the script node object. BTW, this is where I think we went wrong in MID. We tried to define the script language as well as the presentation objects and that proved to be ugly in SGML/HyTime and unsellable given the paucity of available implementation langauge products for that design. Java would have worked better because our requirements could have been met by dividing the responsibilities of the description lanauge and the implementation language better. > In either case, the dynamism isn't in the > HTML, it's in the presentation processor, which is the way the world has > always been. Yes, in the display system. That is why scripting presentation widgets has also always been the easiest way to author and a good DTD-centric design for prototyping dynamic documents. Routing in a VRML object set and selecting functions from a method list in an IDE of presentation objects (eg, VB, Prototype) are very similar ways to represent the same problem. The trick is the extensibility of the design. VRML is extensible without breaking the browser. It is extensible, however, not only because the presentation processor (eg, VRML plugin) is dynamic, but because the presenation plugin is operating within a defined set of services provided by the object framework (browser) for manipulating the values of events in the plugin via the API of the plugin/presentation processor. In this sense, DHTML is the shell language of a standard set of portable operating system interface objects. If one rewrites the VRML in XML, what feature of XML provides the extensibility of VRML protos? Stylesheets? OK. If one uses DSSSL/XSL, how good is that stylesheet language for describing the semantics of real time dynamic 3D simulation objects? What advantage is there in using XSL over Java to do this? Is XSL yet another scripting language? len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|