Lists Home |
Date Index |
For X3D, an example metatag is found in the head similar to HTML:
<meta name='filename' content='myMolecule.x3d'/>
<meta name='description' content='A file describing a molecule'/>
<meta name='author' content='Richard Rabbit'/>
<meta name='created' content='3 April 2006'/>
<meta name='revised' content='4 April 2006'/>
<meta name='generator' content='CML-Edit,
I like the idea of incorporating RDF. This can be very powerful. BTW,
X3D has a loadFromURL node. The issue here is namespace scoping (X3D
namespace rules, not XML) that prohibit messages among inlines.
X3D is a bit different from other markup applications that try to hide
the object-orientation of the application. X3D like VRML before it is a
node/property design from jump that goes in the other direction and
makes objectness the point of the design. It is a bit schizophenic
about that but a better fit than some others because one can easily
build semantics into the representation nodes with internal
interpreters, then route messages among instances of these protos. So
in X3D, extending the language with built-in features is a must given
that it is a real-time 3D simulation language.
What is missing that is a nice-to-have is easier network communication
nodes but those are on several drawing boards.
If CLAX or something like it is to grow, shouldn't it be part of a
collaboration framework? For that to work, the various rendering
classes must communicate and update each other across the network. So
one ends up combining chat/human-talk with the interactive 3D, 2D and
text. Community versions of X3D/VRML already do some of this.
From: Didier PH Martin [mailto:firstname.lastname@example.org]
Let me expand more on the "requirement info set" that an interpreting
environment needs to proper handle the document.
a) every Datuments or web application needs to include some meta data
like for instance, its dependencies with specific versions, modules,
b) We know that relying on the browser to figure this out is a mess most
of the time.
Actually, this kind of meta data can be included in every HTTP
transaction headers but it is very hard to encode HTTP headers in URL or
authoring tools. You'll need to expand the HTTP server basic
functionality with some code to do so. Thus, HTTP headers to specify the
required capabilities are often a show stopper.
The other way is to include the meta information into the document
itself without damaging the document's structure. RDF could be a good
candidate and a client side engine can extract, decipher, interpret this
RDF fragment to check is every PRE-CONDITIONS are met and suggest some
mitigation strategies or re-direct to a downgraded version otherwise.
For instance to take Peter's example, the CML document would include an
RDF fragment to indicate the required capabilities and redirect to
another document containing only images for the other environments in
case these requirements are not met. The user may get the choice to go
for it anyway by not following the suggestions and trying it anyway.
Another way is to add a new parameter (i.e command) to be interpreted;
for example, a parameter pointing to an RDF document containing the
requirements. This way, the requirements are decoupled from the document
and can easily be updated.