[x3d-public] [x3d] V4.0 Open discussion/workshop on X3D HTML integration

[Anita Havele]

On 6/7/2016 9:29 PM, Leonard Daly wrote:

   X3D needs to run in the HTML5/DOM environment. A few nodes need to be
removed, but all capabilities remain. 
   Preliminary proposed V4 document at:
<http://tools.realism.com/specification/x3d-v40>
http://tools.realism.com/specification/x3d-v40 

 

Leonard, thank you for being so diligent on your position on X3D V4. Our
primary goal is to align X3D to work well with  HTML5 and I am glad to hear
that there were some clarifications at this meeting. We have had several
discussions on X3D node sets for X3D V4 to include all existing capabilities
while supporting backward compatibility. 
Would you consider making a formal submission of your  above Preliminary
proposed V4 document to the X3D Working Group. A formal submission is
required to protect us from IPR rules. We would consider this a Daily
Realism contribution. After which the WG will give your contribution due
process. All areas that are agreed upon will be incorporated into the
standard. 

 

There is a lot of work yet to be done. The X3D WG will be concentrating on
X3D HTML5 integration during the next 5 WG meetings before Siggraph. We hope
all key players (X3DOM, Cobweb, XML3D) and others will continue to
contribute. A consensus based solution is what we strive for. We are
grateful for your work and look forward to your many contributions. 

 

Best regards,

Anita-Havele

Executive Director, Web3D Consortium    <http://www.web3d.org/>
www.web3d.org

Phone: +1 248 342 7662     

 

From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Leonard
Daly
Sent: Thursday, June 9, 2016 12:32 PM
To: X3D Graphics public mailing list <x3d-public at web3d.org>; 'x3D WG'
<x3d at web3d.org>
Subject: Re: [x3d-public] [x3d] V4.0 Open discussion/workshop on X3D HTML
integration

 

On 6/8/2016 7:56 PM, Don Brutzman wrote:

Leonard, please review the HTML5 Recommendation again for answers to some of
your issues. 

1. Similar to X3D, HTML5 defines functionality in an abstract way before Two
encodings are defined, in adjacent chapters: loose HTML syntax and strict
XML/XHTML syntax.  Both are compatible because they have reconciled
idiosyncrasies by aligning each with the DOM.  Indeed this dual nature
appears in the title of the W3C Recommendation. 

These links have been posted multiple times in the past: 

    HTML5: A vocabulary and associated APIs for HTML and XHTML 
    https://www.w3.org/TR/html5/ 

    8 The HTML syntax 
    https://www.w3.org/TR/html5/syntax.html#syntax 

    9 The XHTML syntax 
    https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax 


I have reviewed these documents. Without specific reference to my comments,
I don't know how to respond. BTW, at no point did I ever recommend against
the current document structure.







Of note is that X3DOM itself works with both encodings.  Most of the
Fraunhofer examples use HTML syntax.  Over 3000 Web3D examples use the XHTML
syntax, where the XML is directly inserted into the HTML page.  Both work
fine. 


X3DOM works when the containing document is either HTML5 or XHTML5. The
biggest difference between the two is the MIME type sent by the server for
these document types. There are some other minor differences. If X3D is
going to depend on which parser is used on the document (as determined by
the MIME type), then all of this work is hopeless.
https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml






X3D version 4 merely needs to allow alignment with HTML5 rules & relaxations
when running in an HTML5 browser.  Since HTML browsers parse page and scene
data, it seems unlikely that anything we might define would override that. 


It needs to do a lot more than that. There are major differences (as
explained in my previous email) between X3D and HTML. Note that the parsing
of X3D nodes in an HTML5 file is not solely done by the browser. X3DOM (or
whatever application) needs to parse the nodes that are X3D and not HTML.





Regarding events: 
-  DOM events pass a value from one element/node to another, always as a
string. 
- X3D events pass a value from one element/node to another, always as
timestamped typed value - which have defined expressions as a string. 
- Reconcilable. 


DOM events are not a string, but an object. The object contains more
information than the value (as a string) and a timestamp, but the value is
always passed as a string.






Given the stability of browser environments, which took 14 years to achieve
when going from HTML4 to HTML5, we have a better environment for achieving
excellent compatibility than at any time in our history. 

Regarding implementations: it is not reasonable to ask X3D players to always
act in a DOM way.  They are different environments.  Those that want to use
DOM for operations are welcome to. 


That was my first point. I was solely looking that the HTML5 environment.
The way the Consortium proceeds is a business decision that is left to the
BOD to make. Since it is a business decision, it is important to look at
market share, # users, existing related applications, and other
business/marketing factors before making a choice. A decision to support
non-HTML5 environments can take valuable resources away from pursuing HTML5
environments.






2. Regarding X3D Script and X3D prototype: don't use them if you don't want
them.  But don't forbid others from using so much great work, repeatedly
implemented with success.  X3D would be much smaller and poorer without
prototype extensibility, it allowed us to build large portions of the
language. 


There is a fundamental problem with X3D Script nodes in HTML5. Without
resolving that, there is no point in even opening a discussion on PROTOs. 







3. Regarding Consortium:  you seem to think that some kind of decision is
needed.  We have a strategy, and we have lots of eyes on it, and we have
steady progress, and we can use lots more.  Encouraging activity is not
accomplished by opinions or subjective insider decisions.  We have goals,
requirements, process and proven track record across 2.5 versions of VRML, 4
versions of X3D, H-Anim, multiple encodings, multiple language bindings, all
of which continue to grow compatibly with increasing quality & consistency
in each passing month.  None (I repeat, none) of that was achieved by
"leadership decisions" that told volunteers how to spend their time.  All of
that progress was achieved by cooperative engagement, building consensus,
and working hard to implement and evaluate.  Specifications, example scenes
and software implementations are the proof points. 


Decisions need to be made because there are insufficient resources (all
volunteer at this point) to pursue a market (HTML5) and historical
development (X3D V3). If I am reading your words correctly, you are
advocating for a leaderless organization. Since no organization is really
leaderless, then it is being pushed by the desires of a few non-leader
leaders, who are making the decisions to best suit their needs.







Not listening to repeated answers makes repetition of questions of limited
use.  "Too long didn't read" indeed. 


Not listening to repeated answers makes repetition of questions of limited
use.  You have not responded to my specific points where I identified
significant issues: X3D-Script nodes and event handling differences in an
HTML5/DOM environment. Perhaps you do not wish to support X3D in that
environment. If so, come out and say it. It will stop a lot of this
disagreement and we all can go down separate environment paths.

Leonard Daly







Using your issues to help define issues/pros + cons/resolutions can
contribute to a constructive working group process that has a lot of
usefulness. 

Traits like "dominant" or popular or common or whatever can be good
guidelines, but they are not the bottom line.  Well-defined, repeatable
functional correctness is.  This is why we have specifications, examples,
implementation and evaluation - for HTML as well as X3D.  This is why we
have cooperation between standards development organizations like W3C and
Web3D.  That is why we have standardization strategies for HTML5, MAR/VR
etc. all worked out collaboratively and posted online.  That is why today we
are NOT saying "well a couple of people made a personal decision 5-10-20
years ago that we are forced to live with." 

I hope that this note helps explain to everyone how we continue to make
progress. 

  
On 6/7/2016 9:29 PM, Leonard Daly wrote: 



Wednesday (8 June 2016) X3D WG call is dedicated to discussion X3D V4.
Several people (including myself) have commented on the ideas over the last
couple of years. I am going to state my current position here. I don't think
it differs much from my position a year ago; however, I'm sure there have
been some clarifications. 

tl;dr 

    X3D needs to run in the HTML5/DOM environment. A few nodes need to be
removed, but all capabilities remain. 

    Preliminary proposed V4 document at:
http://tools.realism.com/specification/x3d-v40 


I am going to start my position with a response to a question asked by John
Carlson on a different list (x3dom-users): are we adding HTML5 capabilities
to X3D or 3D (X3D in particular) capabilities to HTML5? 

HTML is the dominant environment world-wide. It provides text, image, 2D
graphics (SVG), video, and other capabilities. The size of the HTML5
development community far exceeds the total of the entire X3D community.
Forcing HTML5 into X3D is a losing game right from the start -- whether you
want all of HTML5 or just a portion. So in my mind, the only choice with a
future is to add 3D to HTML5. Running in the HTML5 environment means full
integration with the HTML5 DOM (or later versions when they happen). BTW,
there are already a number of non-Web3D Consortium efforts to do so. We are
not out in front of the effort and are about to be made irrelevant. There is
no more time for delays or debates. 

So now that the environment is settled, it is important to identify what in
current X3D (V3.3) is incompatible with HTML5. There are only three obvious
features - Script node, event handling, and case sensitivity. There are
other capabilities that are dependent on these capabilities -- I'll discuss
those later. 

Starting with the easiest one first - case sensitivity. HTML5 is case
insensitive. Relaxing X3D's rules on that allows existing X3D code to run in
a browser. If everything gets converted to lower-case prior to handling
(except quoted strings), then there is not a problem. 

There is an obvious naming incompatibility with Script -- the name. HTML5 is
already using that name. Under my initial condition there cannot be an X3D
Script node. That does not mean all scripting functions are given up. HTML5
provides a wonderful script interface a more flexible structure. In X3D,
Scripts are meant to process events, so the function argument is always an
event (except for X3D-Script internal functions). Functions in HTML5 are a
lot more flexible and can include events, objects, scalars, arrays, etc. So
there is no loss of functionality by giving up X3D-Script. 

Event handling is different between HTML5 and X3D. In X3D events are
"routed" from one node to another. They allow one part of the scene graph to
"talk" to another part. In HTML5, events "bubble-up" from the originator to
the event through any handler that may be attached to any parent node of the
originator until the event is cancelled. In all of my design work on V4 I
have not found any instance where HTML5-Scripts could not provide the same
functionality as X3D-Script+ROUTE. It requires a little different mind-set,
but the HTML5 mind-set is very familiar to JavaScript programmers and other
front-end developers. I also believe that a graphical development interface
can be built that completely simplifies the differences. 

The biggest issue I have seen with event handling is scene graph updating.
X3D updates the scene graph once all non-looping events in the cascade have
completed. After the scene graph is updated, a new frame is rendered. This
can cause a large delay between rendered frames. HTML5 renders as it goes.
Rendering happens asynchronously to changes to the DOM. There is no concept
of accessing the DOM before or after all events for that frame. X3D worlds
that depend on that feature will probably not be able to be ported to X3D
V4. 

Summarizing the three incompatibilities - with the exception of some event
processing, none will prevent X3D from doing what it currently can do and
all can be easily migrated to the HTML5 environment. 


There are a number of features that I think should not be included in X3D
V4, but these are just features and not fundamental capabilities. These
include all nodes that generate geometry (e.g., Extrusion, ElevationGrid,
Text) with the exception of simple solids and perhaps a couple of additions.
My view here is based on the availability of free modeling software (e.g.,
Blender) that does all of the above, and a lot more efficiently than X3D
can. Also by not including these nodes, the resultant models will look
better. 

Lastly (for now), I believe that there is no purpose for a PROTO node.
Without a X3D-Script node, PROTOs just become convenience generators. To
replace that feature, I am proposing a MACRO node that takes X3D and does
string substitution prior to inserting the result into the scene graph (and
DOM). I have a partial implementation of this for X3DOM. 

Summarizing: The Consortium needs to get out and lead the way for 3D on the
web (and this includes VR) or it will be by-passed and left with the relics
of history like blinking text, and Flash. The environment must be HTML5/DOM
and X3D must stay current with the web environment. There will always be
someone who needs something specialized that does not use a web environment,
but those will be individual cases and not worth significant volunteer
efforts. 

-- 
*Leonard Daly* 
3D Systems & Cloud Consultant 
X3D Co-Chair on Sabbatical 
LA ACM SIGGRAPH Chair 
President, Daly Realism - /Creating the Future/ 



all the best, Don 

 

 

-- 
Leonard Daly
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - Creating the Future 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160610/f1c4e682/attachment-0001.html>