[X3D-Public] Minutes: X3D-HTML5 Working Group Nov 24 2009

John A. Stewart alex.stewart at crc.ca
Tue Dec 8 06:09:40 PST 2009


What: 		Web3D HTML5 meeting November 24 2009
present: 		John Stewart, Joe Williams,Johannes Behr, Don Brutzman,  
Anita Havelle.
absent: 		

Web page: 	http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5
-----------------------------------------------------------------------------------------------------------

(Editors note: as these minutes are now being distributed via email  
and web page links, I will attempt to make them less cryptic than when  
the distribution was local to the Web3D Consortium - John A. Stewart)



----------------------------------------------------------------------------------------------------------------------------------------------
1) ACTION: Anita Havelle - will send out the message outlining what we  
did at the TPAC. Will pass this through us for verification before it  
is sent to all the X3D lists.

Update: Nov 24; email sent to lists, but not on web3d.org front page  
yet. Anita wants to expand the message, will  have more info on x3dom,  
and html5 and wil put this together on the web site. She and Johannes  
Behr are currently exchanging emails.



----------------------------------------------------------------------------------------------------------------------------------------------
2) W3C Bug 8238: competing 3D model serializations. See:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238

JohnS: November 9; Sent a request to Maciej Stachowiak (W3C)  
requesting clarification on what he meant in Comment #4:

(Note: I have prepended email-reply quoted text with either (JohnS) or  
(MS) depending on the originator)


Maciej;

Nice to meet you at the TPAC last week.

I hope you don't mind; I'm going to bring some of your comments from  
within Bug 8238 out to the mailing list so that I can ask for  
clarification.

(MS) "Tentatively, I would not be in favor of an X3D-specific  
mechanism in the parser. X3D is not supported directly by UAs, and  
it's not clear if it ever will be (since there are competing 3D model  
serializations with similar or greater levels of traction)."

May I ask what other 3D model serializations you have in mind?

(MS) "... But it doesn't make me, as a UA implementor, feel more  
motivated to add built-in parsing complexity for a feature to be  
implemented by third-part code."

There are a number of open-source code bases for X3D out there;  
Johannes created the X3Dom javascript implementation that we  
demonstrated last week; I have FreeWRL, a OSX/Linux/Windows native  
implementation, and there are others.
I am not yet fully aware of the W3C process, nor of individual  
member's requirements, but could such open-source codebases be of  
interest to UA implementors? Hopefully it is apparent that we wish to  
work with the W3C to promote X3D as one possible candidate for 3D  
rendering and interaction within HTML5.

I look forward to further dialogue.



On November 17, Maciej responded by:

(JohnS) "May I ask what other 3D model serializations you have in mind?"

COLLADA.
O3D (has a JavaScript API that creates a retained-mode scene graph,  
and a JSON-based serialization).

These seem to have more active support and interest in at least some  
quarters than X3D.

(JohnS) "There are a number of open-source code bases for X3D out  
there; Johannes created the X3Dom javascript implementation that we  
demonstrated last week; I have FreeWRL, a OSX/Linux/Windows native  
implementation, and there are others.
I am not yet fully aware of the W3C process, nor of individual  
member's requirements, but could such open-source codebases be of  
interest to UA implementors? Hopefully it is apparent that we wish to  
work with the W3C to promote X3D as one possible candidate for 3D  
rendering and interaction within HTML5."

If X3D looks like the right technology for the problem space, then we  
will definitely want to implement it natively. What I'd be hesitant to  
do is to expend effort on parsing hooks without doing the rendering  
natively as well. I don't think we're ready to bet on X3D at this  
time. But we (Apple) do think that a logical next step after WebGL is  
some sort of retained-mode mechanism for 3D graphics.

Regards,
Maciej



Update November 24: John Stewart sent a response composed by the  
members of this working group. The response went out to Maciej by  
email on November 19.

Hi Maciej;

Thanks for the response.

(MS) "COLLADA.
O3D (has a JavaScript API that creates a retained-mode scene graph,  
and a JSON-based serialization).

These seem to have more active support and interest in at least some  
quarters than X3D."

Collada and X3D are in many ways complementary; X3D and Collada do  
have a working relationship.

We believe that HTML5 needs a strong deployment format, like X3D, for  
HTML5/DOM integration. Our reasons follow.

3D (X)HTML-ized retained graphics requires a royalty-free, open,  
standardized XML-encoded format. At first look, both Collada and X3D  
are suitable candidates, but below I will indicate why X3D is the  
clear winner.

O3D, while a great design from a graphics-programmer point of view,   
does not support a declarative XML-Model which could be directly  
mapped to live DOM elements. (We view it as synonymous with WebGL; eg  
Johannes Behr's group are planning to write an O3D backend, to  
compliment the the WebGL backend, for x3dom.org)

Collada is a great format for a specific purpose: It is designed as an  
interchange format to transport and manage specific 3D assets. The  
Collada specification does not include, unlike X3D, a runtime or event  
model, which is needed for per-frame updates on the 3D-side (e.g.  
animations).

We believe that 3D in HTML5 will be crippled if it chooses a 3D format  
that does not have a runtime environment that supports dynamics in the  
declarative model.

Dr. Johannes Behr of Fraunhofer has given the following example that  
might put more light on the situation:

"Collada is really a data-container if you would like to go from tool  
A to B to C and would still like to get your A-specific extensions in  
C even so B does not know about it. The disadvantage is, that almost  
every Collada-tool writes and adds own extensions to the data. The  
Collada format is made for this extensibility and it is not a bug but  
feature of the design.

Take, for example, the spore model which Vladimir used in his first  
WebGL showcase:

                     ftp://ftp.igd.fhg.de/outgoing/jbehr/Amahani-dae.zip

It uses some own and Maya specific extensions and can therefore not be  
opened in other tools like e.g. the "Snow-Leopard Preview" even though  
it is a standard- and schema-compliant file.

Collada therefore is a container to get data from tool A to B without  
losing parts. But it's not a delivery or deployment format.

There are similar cases for e.g. image or text files. Many people use  
psd-files to store images with all layers and to get from one tool to  
another but one does not distribute the psd file on the net. The same  
goes for text-files. Everyone uses .doc or .odf for text but pdf for  
the final delivery. Therefore there is always this duality for  
different areas.

The same process goes with 3D. Use Collada in your pipeline and an  
delivery format (e.g. X3D) in the final runtime.

And this is not just my opinion:  For more background information  
about how Collada and X3D relate and why “X3D is ideal for the Web”  
please read the Whitepaper by Rémi Arnaud (founder of the COLLADA  
initiative) and Tony Parisi, (co-founder of VRML, and X3D architect): http://www.khronos.org/collada/presentations/Developing_Web_Applications_with_COLLADA_and_X3D.pdf 
  )
"


(MS) "If X3D looks like the right technology for the problem space,  
then we will definitely want to implement it natively. What I'd be  
hesitant to do is to expend effort on parsing hooks without doing the  
rendering natively as well. I don't think we're ready to bet on X3D at  
this time. But we (Apple) do think that a logical next step after  
WebGL is some sort of retained-mode mechanism for 3D graphics."


We agree with the native implementation statement.

There seems to be a requirement for an abstraction for retained-mode  
3D graphics so that 3D graphics can not only be cross-platform but  
also allow for technological improvements that will come over time  
with improvements in both hardware and lower layer graphics drivers.

Dr. Behr's x3dom.org is an excellent first step to allow design and  
testing of tight X3D-HTML5 integration, but is hampered performance- 
wise by it's implementation (Javascript) running on top of a pseudo- 
lower layer API (WebGL). There are open-source, natively written,  
multi-platform, multi-threaded X3D codebases that are not hampered by  
the Javascript/WebGL performance limitations.

We believe that HTML5 should use a retained-mode model (or, "scene- 
graph") which can be directly mapped to a live DOM-Tree for easy  
access and programmability, and X3D looks like  an excellent candidate.

Thanks again for the dialogue;

-----------------------------------------------------------
John A. Stewart
(representing the Web3D Consortium)

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



----------------------------------------------------------------------------------------------------------------------------------------------
3) W3C Bug 8238: Sam Ruby and list of X3D Elements and Attributes.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238

This list contains abstract types, MF and SF enumerations, and other  
keywords that need not be captured by HTML5.

ACTION - Don - will autogenerate element and attribute lists from the  
schema and send it along to the HTML5 wg, in response to bug 8238.


November 24: no change.


----------------------------------------------------------------------------------------------------------------------------------------------
4) Case independent encoding of X3D.

Question: Should we have an encoding that closely matches HTML5?

If we do, HTML5 content model -  our goal would be that if we have an  
all lower case encoding that a parser that reads in a relaxed parsing  
mode, we would promote the capitalization for the DOM model interaction.

Noted that in X3D, there are no ambiguities created by ignoring case;  
eg, there are no conflicts for "Interpolator" and "interpolator".

Also noted that HTML5, case does not matter, but the DOM is case  
sensitive.

ACTION: All - do we relax case on xml parsing in general. (background  
- html5 is case insensitive; can we cut and paste)


November 24:

Don - case insensitive is their terms for "lax".

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;


DONE ACTION: Johannes - x3dom.org, make parser relaxed in terms of  
case sensitivity. Changed x3dom.org implementation and added example  
with mixed up case encoding.


----------------------------------------------------------------------------------------------------------------------------------------------
5) General access to HTML5 group minutes.

The minutes are sent to members of this group, and to the public-x3d  
mailing list. They are also archived to the Web3D internal archives,  
but should be easily located by the general public.

ACTION: JohnS - add wiki section, and add hypermail links to minutes.

November 24: not done yet. Had difficulty accessing Web3D.org wiki  
from inside work firewall.

Don - hint: to do this, left square bracket, url, space, prose "oct  
minutes right square bracket.


----------------------------------------------------------------------------------------------------------------------------------------------
6) Discussion on Void element (comment 6 in bug 8238)

November 24:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238


hint: the only contained content in any element is eg: the javascript  
url code in a script node (Shaders, too)

Don: Void element - talking about a singleton element where they have  
omitted the closing slash at the end of the tag.

Joe - void element became what xml calls empty element.

Johannes - has definition... http://dev.w3.org/html5/markup/syntax.html#syntax-elements

Don - every element can have metadata child, so that is a problem.  
Also, there are a handful of things that are not an element; like ROUTE.

Don - we can give a list of nodes that have metadata and nothing  
else....

Joe - HTML in principle does not recognize the self closing tag. And  
yet, if you put that in all the browsers;  the browsers are NOT  
rejecting it as invalid content.

Don - Example: if we have 3 transforms in a row; how do you tell if  
they are nested children or just siblings if not closing tags?

Don - do we have any examples of void tags in html?

Joe - Yes, void tags - metadata, parameters,....

Don - do html5 have a list of void tags for html; if they do not have  
a list, then we have to give one back to them.

Johannes - void elements must not have an end tag.

joe - if you put a <br/>, all tested browsers will not mind.

Johannes - but, this is not spec - it is a relaxing of spec input  
parsing rules.

Joe - but the browsers are ok with this. so void is the same as empty  
in both html and xhtml.

joe - so in a way, the emphasis should be on html5 be ok on the  
closing tag.

ACTION: Joe to send a couple of examples of this.

----------------------------------------------------------------------------------------------------------------------------------------------
7) x3dom X3D integration issues.

Johannes - x3dom.org testing; , expose javascript object part that  
maps to fields to try to map to SAI so that one can do faster updates  
rather than ASCII-ized DOM, as per what the SVG people have done.  
Would like to implement this and test to determine efficiency of  
asking the DOM element for the javascript object so you can manipulate  
this directly.

One nice thing is that one can use all the X3D definitions of the SAI  
for the fields; can spec a sub part of SAI spec for this.

Noted: SVG currently requires this methodology for performance and  
convenience.

Don - so, need DOM Extensions for X3D spec.

Don - the more we do this, the more we reduce the barriers of entry.  
This is why Sam Ruby (W3C) wants to pose us as a case for central  
extensibility vs decentralized extensibility.

Johannes - might be able to encode as JSON;

Joe, JSON is just a transport kind of thing.....

Johannes; have to do InstantReality release, will work on this x3dom  
extension over christmas.


-----------------------------------------------------------
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