xml-dev - XSL/XML/XLL and VRML (was: Re: Conditional actions in XSL?)

[len bullard <cbullard@hiwaay.net>]

>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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)