[x3d-public] dual use of script tag in HTML environment

[Andreas Plesch]

>
> Message: 4
> Date: Fri, 11 Nov 2016 10:08:32 -0800
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
> Subject: Re: [x3d-public] dual use of script tag in HTML environment
> Message-ID: <b33aef12-be8b-8384-7926-b57ee82b669f at realism.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Andreas,
>
> > I am trying to make cobweb and cobweb_dom html5 compatible, so there
> > is no requirement to use xhtml. xhtml is not used much at all and may
> > face extinction.
> >
> > The implication for x3d spec. is that it would be better to have the
> > field definitions in an attribute rather as in child nodes. Something
> like
> > <script ... fields=' "inputOnly SFBool isOver" "outputOnly SFColor
> > diffuseColor_changed" '>
> > That would be also more concise.
>
> This would get really messy if a field were inputOnly MFString and you
> needed to specify multiple values in form '"v1" "v2" "v3" ...'. Also if
> there are a lot of fields, especially with a large collection of values
> (e.g., MFVec3D) you could run into attribute value character limitations.
>

I had a feeling that this was already discussed at length, probably at the
time when the xml encoding was developed.

To clarify, the MFString case would be fields=' "inputOnly MFString
myString ' "a" "b" "c" ' " "nextField" '

where ' "a" "b" "c" ' is the initialValue of myString .

This is indeed quite messy and hard to parse. The only way around that I
can think of is to not be able to specify initialValues explicitly.
Instead, common
default values for each type would be defined, and scripts required to
initialize
to other values if necessary. This is a deeper change but I would say it is
more natural
to initialize field values in the script.

If limitations to the length of attribute values would be a concern, they
would need
to be a concern for the <field> nodes as well as for MFVec3f fields in
general
which need to have long lists for complex geometries. If there is a
situation
where this limitation plays a role, the script itself could initialize to
long values.

But given that currently this suggestion would only benefit cobweb, I doubt
that there
is enough motivation to advance such an amendment. Unless there is enough
of a
benefit to x3d authors in general which may or may not be the case.


> If X3D is to be declarative, then all programming nodes (i.e., Script
> and Shader) should be eliminated and new nodes added that provide for
> the most commonly needed features.
>

The existence of the script node points to an observation that often a mix
of declarative and
imperative programming is desired by many.

Currently, in cobweb the script node has the benefit of being part of the
event cascade
which is mostly useful for time accurate simulations, eg. a script can rely
on the timestamp
and that all other elements of the world are synchronized to that exact
timestamp.
Another benefit is that it performs a little better than DOM scripts which
need to go through
the DOM but not better than external scripts which use the SAI without
going through the
DOM.

Custom shaders need to be in the form of webgl programs. x3dom has
http://doc.x3dom.org/author/Shaders/CommonSurfaceShader.html
which is attempt to capture the most commonly used shaders in a few
parameters.
But I feel that many shader users would want to go beyond that.

Programmatic access and support can be added through new capabilities
> that allow scripts to access scene information, but not be controlled by
> the event system. Perhaps some nodes that convert events back and forth
> to direct access would solve much of the problem.
>

That sounds interesting. Did you start to think about something more
specific ?

Andreas


-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161111/4aef9d2a/attachment-0001.html>