XSL/XML/XLL and VRML (was: Re: Conditional actions in XSL?)
cbullard at hiwaay.net
Thu Jan 29 03:30:35 GMT 1998
>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
ROUTE BoxTimer.fraction_changed TO BoxPostitionInterpolator.set_fraction
ROUTE BoxPositionInterpolator.value_changed TO Box.set_translation
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
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
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
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
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
how good is that stylesheet language for describing the semantics of
dynamic 3D simulation objects? What advantage is there in using
XSL over Java to do this? Is XSL yet another scripting language?
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev