VRML and XML

[len bullard]

W. Eliot Kimber wrote:

> Len,
> 
> You are confusing the specification of the data with the execution of
> the specification.  It's like saying there'd be some difficulty in
> representing a programming language using XML syntax--there's not.

No.  SGML-bred, I understand that completely.  MID was a good 
laboratory for those concepts.

I am looking at the practical applications and wondering 
if there are any right now.  *Internet time* has taught me 
to be self-restrained about what is possible vs what is worth 
the effort given the need to get the software to market.  Whatever 
else the VRML community does, they are very pragmatic about that. 
The VRML community is almost completely unique in the close 
symbiotic relationship in the development lists of the the 
content and implementation engineers. It has been a raucous 
but very effective relationship.

A syntax specification language can represent whatever needs to 
be represented.  It has been done several times with SGML as 
we both well know.  Building a production-worthy useful language 
is not a theoretical exercise however.  For an XML version of 
VRML to be useful, there must be some requirements for it which 
ISO VRML (VRML 97) does not meet.  
 
> Using a style language is useful for the same reason it is in SGML: I
> want to apply different styles to the same basic data objects.  Asking
> why it's useful here is like asking why you need styles if you have a
> font tag and I know we both know the answer to that one.

Yes.  If one is considering building reusable objects in scenes, 
there may be something useful there.  However, VRML97 already 
contains protos and external protos which satisfy that requirement 
and are expressed in an established syntax for which there are 
already good and rapidly improving implementations.  VRML is designed 
around an object model and in some respects, is ahead of DOM.

> The fact that the presented result happens, in some presentation styles,
> to be interactive is completely irrelevant to the issue of representing
> the data using XML.

In the theoretical sense, yes that is true.  In the practical sense of 
fielding applications, it is also irrelevant.  The *presentation styles*
of 
3D graphics are not that complex and it may be the case that within 
the current and soon to be fielded platforms, the size of the instance, 
the speed of the parse, the building of the internal structures, the 
efficiency of the external interfaces are the critical aspects of the 
design.  

> A better question might be: does XLL (or HyTime event schedules or some
> combination thereof) provide anything useful in representing the
> relationships among the nodes, which is all an event model does (define
> relationships or behavior associated with relationships).

Yes.  I think that is the more interesting question.  The linking of 
VRML is still a list of URI/URLs where the intended semantic is to 
try the first one and if that doesn't work, try the next one, etc.  
VRML anchors are not that sophisticated.  It was said that because 
of script nodes, they did not need to be.  It is an interesting decision 
in what it expresses as the preference of the VRML designers with 
regards to abstractions of semantic linking.  However, see below for 
a real problem which the URLs, scripts, and event models don't 
solve given the current VRML expressive limits.
 
> XML only operates at the document representation syntax level, so it can
> have nothing to say about the semantics of the data represented. On the
> other hand, XLL and HyTime (and DSSSL and XSL) operate at the semantic
> level and therefore may have lots to say about the semantics of the data
> represented.

Yes.  I think that the project should look at the DOM for its potential 
to unify the document handling framework.  IOW, would the benefits of 
minimizing the number of interfaces for handling documents of 
multiple notations outweigh the performance benefits of multiple, 
notation-specific APIs?  Given that the building of a Web page 
is now approaching the complexity of a Visual Basic application, 
the size of the browser framework (cum portable operating system) 
is getting above 15MB, and the willingness of the vendors to 
increase the number of 5MB+ plugins (notation browsers) within 
the framework deliverable is waning, there may be benefits.  
However, in the case of VRML97, at this time, the performance 
(frame rate, load time, time to load and start included files 
such as MPEG, WAV, streaming media), is critical.  

BTW, in the timing problems, VRML browsers still have sticky problems
particularly 
in execution where indeterminate conditions can occur.  This makes 
some problems of sequencing almost intractable for the content 
providers as the machine characteristics are critical.  IrishSpace 
pushed the envelope.  The script I mailed to you is the opening 
from that project.  Just for grins, try to figure out sometime 
how to get the asteroid to always hit the Amazon Basin and start 
the transparency that creates the ashcloud to happen exactly 
when the script says it should.  The problem is one in which
the audio has begin times and event outs for when the audio is 
done, but no way to state exactly where an event within the 
audio occurs.  

len

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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)