Lists Home |
Date Index |
- From: len bullard <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 15 Jan 1998 22:12:27 -0600
W. Eliot Kimber wrote:
> 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*
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
> 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
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
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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)