[X3D-Public] HTML5 Web3D Working Group January 5 2010
John A. Stewart
alex.stewart at crc.ca
Tue Jan 12 06:48:58 PST 2010
X3D-Public mailing list members - here are the finalized minutes for
the January 5 2010 meeting.
What: Web3D HTML5 meeting January 5 2010
present: John Stewart, Johannes Behr, Joe Williams, Don Brutzman,
Anita Havelle, Leonard Daly.
absent:
Web page: http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5
----------------------------------------------------------------------------------------------------------------------------------------------
6) Discussion on Void element (comment 6 in bug 8238 - see link below)
November 24:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238
December 8:
JohnS: will put on hold until html5 browsers get more settled. I will
keep the topic header in minutes, but will remove previous text until
topic has been reopened.
(older minutes in this topic removed; available on line - eg http://www.web3d.org/pipermail/x3d-public_web3d.org/2010-January/000581.html)
----------------------------------------------------------------------------------------------------------------------------------------------
7) x3dom X3D integration issues.
(older minutes in this topic removed; available on line - eg http://www.web3d.org/pipermail/x3d-public_web3d.org/2010-January/000581.html)
January 5 2010:
Johannes sent the following via email:
Some example how an integration could look like with and without SAI:
1, 2 and 3a already work in X3DOM. 3b (the SAI part) is open for
discussion.
-----------------------------------------------
1) Runtime Integration (no object or embed needed)
...
<X3D xmlns="…" >
<Scene >
<Group id='root' />
<Shape>
<Appearance>
<Material DEF='mat01'/>
</Appearance>
<Cone/>
</Shape>
</Scene >
</X3D>
...
-----------------------------------------------
2) javascript function to Add/Remove nodes via DOM changes
(appendChild() is a standard DOM function)
…
function addChild()
{
var s = document.createElement('Shape');
var b = document.createElement('Box');
s.appendChild(b);
var ot = document.getElementsById("root");
ot.appendChild(s);
}
…
-----------------------------------------------
3a) change attributes via standard DOM functions
…
function changeColor(flag)
{
var mat = document.getElementById('mat01');
mat.setAttribute ("diffuseColor", (flag ? "0 0 1" : "1 0 0"));
}
-----------------------------------------------
3b) change fields via SAI functions
…
function changeColor(flag)
{
var mat = document.getElementById('mat01');
// get SAI Field element
var color = mat.getField("diffuseColor");
// use SAI functions to set the field directly
color[0] = 0.2;
color[1] = 0.3;
color[2] = 0.4;
}
…
Johannes - setAttribute - (example 3a) always has to be ASCII encoded
strings, which is slow.
Johannes - would like to have SAI-field information from the node,
(see 3b, above) so uses a very small subset of the SAI spec.
This will speed up accessibility to fields.
Don - Anything which uses a DOM function - we currently do not have
behaviours defined in X3D spec for DOM. We have to decide whether a
callback is necessary to tell X3D browser if a refresh is required.
(setting a "dirty bit" for recalculation)
Johannes - this refresh should be automatic if using same as with SAI
spec.
----------------------------------------------------------------------------------------------------------------------------------------------
8) Updates to HTML5 spec.
From Item 4) from previous minutes, the following paragraph:
"Don - what the spec says for SVG and MathML will tell us
what we should do. Don will go
through spec on upcoming trip overseas; see below. Returns
19th December".
(older minutes available on line - eg http://www.web3d.org/pipermail/x3d-public_web3d.org/2010-January/000581.html)
December 1: No change.
...
January 5 2010:
Don - please review the following link:
http://x3d.svn.sourceforge.net/viewvc/x3d/www.web3d.org/x3d/content/html5/HTML5RecommendationAdditionsForX3D.html
We can propose this, there are no show stoppers.
Specific suggestions for the HTML5 document editor - can be cut and
pasted into their spec to make it very easy for them to incorporate
changes.
Motivation section in above link - written mainly for web authors.
Section at end for us (TODO), we might want to rephrase so it is more
understandable for others.
Don - will post to X3D-Public list.
Anita - Motivation - maybe want to interchange file format, in
addition to a runtime architecture - X3D can fill the role of both.
Don - important section to look at: issue b: regarding Decentralized
vs Centralized Extensibility.
Don - should we submit this to HTML5 and X3D-Public?
John - Yes;
Johannes Yes;
Joe - wondering why we want to stick out toe into runtime here;
(Motivation section) - SVG
Don - the motivation focuses end users, authors and browser builders,
not spec writers.
Joe - ok.
ACTION: Don to submit to the HTML5 and X3D-Public lists.
----------------------------------------------------------------------------------------------------------------------------------------------
9) External SAI Scripting tests.
December 1:
Don Brutzman by email: "we need to get some external SAI examples
that show
javascript in web page talking to an embedded X3D scene."
December 8:
JohnS - FreeWRL uses SAI externally from Java, C, and Tcl (ie, not
embedded in a Script node). The
Javascript classes have been "blocked in" but code has not been tested
nor made active in releases yet.
December 29:
Joe - mailed an SAI example from external script.
All to review.
Don - wants examples of routing of events via SAI.
Len - 2 years ago, Vivaty supports sai; now support is not supported.
Bitmanagement and Octaga have some form of SAI.
Don - whether we have implementations or not, if we have an example or
two, we can use it to ask companies "hey where is our scripting
interface?"
Len - SAI spec does not tell how to start the connection so that each
browser can implement SAI differently.
Johannes - if we put HTML4 example out there, we need to put the HTML5
equivalent - so do we want HTML4 examples?
Don - we need a set of examples that work in either environment. - we
are asking our companies to do the right thing when X3D is encountered.
Joe, Don, Len: Examples are being distributed via email. Examples will
be formalized by next meeting.
January 5 2010:
Out of time - no discussion.
----------------------------------------------------------------------------------------------------------------------------------------------
10) 3d-test.com interview.
December 8:
JohnS - We have been asked by Benoit Vandangeon to participate in an
on-line interview for
http://www.3d-test.com. We will discuss this by email, and will return
a group-derived answer by 20 December.
December 29:
Anita - news item on Web3D.org based on interview.
JohnS - Javascript comment and precision issues found by x3dom - if we
have an floating point issue; we will work with the javascript people
to get issues resolved.
Johannes; Don; Johns: Javascript by default supports doubles.
Don - here is the text from the Ecmascript spec outlining that all
numbers are double:
Standard ECMA-262
3r d Edition - December 1999
ECMAScript Language Specification
===================
4.3.19 Number Value
A number value is a member of the type Number and is a direct
representation of a number.
4.3.20 Number Type
The type Number is a set of values representing numbers. In ECMAScript,
the set of values represents the double-precision 64-bit format IEEE 754
values including the special “Not-a-Number” (NaN) values, positive
infinity,
and negative infinity.
===================
JohnS: but, most GPUs only support 32 bit internally.
Joe: some are 64 bit now:
JohnS: very true, but they are not widely distributed, like on pdas,
etc.
JohnS: so two potential javascript issues:
1) there are potential 64 <--> 32 bit conversions being performed at
all gpu interactions;
2) if Javascript uses OpenCL or CUDA for calculations, it will have
precision difficulties.
January 5 2010:
Out of time - no discussion.
-----------------------------------------------------------------------------------------------------------------------------------------------
11) Javascript and DOM security.
January 5 2010:
John Carlson wrote an email questioning DOM and X3D integration. see:
http://www.web3d.org/pipermail/x3d-public_web3d.org/2010-January/000575.html
Len: Maybe this is a problem with javascript security? should not be
able to go cross-domain in Javascript. If so, this is not an X3D
problem, but a Javascript issue.
John - a design problem with javascript, or an implementation problem?
Len - Javascript - design problem; the net changed the way javascript
is used. General community of content - some of which may be hostile
to other content.
Don - wants to read and study more.
Don - creating a new bullet in wiki about this.
Don - do not have a general security issue section concerning X3D in
general.
-----------------------------------------------------------
John A. Stewart
Team Leader: Networked Virtual and Augmented Reality
alex.stewart at crc.ca
Network Systems and Technologies -
Systemes et technologies des reseaux
Communications Research Centre Canada |
Centre de recherches sur les communications Canada
3701 Carling Ave. | 3701, avenue Carling
PO Box 11490, Station H | CP 11490, succursale H
Ottawa ON K2H 8S2 | Ottawa (Ontario) K2H 8S2
http://www.crc.ca
More information about the X3D-Public
mailing list