<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/8/2016 7:56 PM, Don Brutzman
wrote:<br>
</div>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">Leonard, please review the HTML5 Recommendation again
for answers to some of your issues.
<br>
<br>
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.
<br>
<br>
These links have been posted multiple times in the past:
<br>
<br>
HTML5: A vocabulary and associated APIs for HTML and XHTML
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html5/">https://www.w3.org/TR/html5/</a>
<br>
<br>
8 The HTML syntax
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html5/syntax.html#syntax">https://www.w3.org/TR/html5/syntax.html#syntax</a>
<br>
<br>
9 The XHTML syntax
<br>
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax">https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax</a>
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml">https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml</a><br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
Regarding events:
<br>
- DOM events pass a value from one element/node to another,
always as a string.
<br>
- X3D events pass a value from one element/node to another, always
as timestamped typed value - which have defined expressions as a
string.
<br>
- Reconcilable.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
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.
<br>
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
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.
<br>
</blockquote>
<br>
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. <br>
<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
Not listening to repeated answers makes repetition of questions of
limited use. "Too long didn't read" indeed.
<br>
</blockquote>
<br>
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.<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<blockquote cite="mid:95822424-bb02-edf9-74c6-fc2c61cbc199@nps.edu"
type="cite">
<br>
Using your issues to help define issues/pros + cons/resolutions
can contribute to a constructive working group process that has a
lot of usefulness.
<br>
<br>
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."
<br>
<br>
I hope that this note helps explain to everyone how we continue to
make progress.
<br>
<br>
<br>
On 6/7/2016 9:29 PM, Leonard Daly wrote:
<br>
<blockquote type="cite">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.
<br>
<br>
tl;dr
<br>
<br>
X3D needs to run in the HTML5/DOM environment. A few nodes
need to be removed, but all capabilities remain.
<br>
<br>
Preliminary proposed V4 document at:
<a class="moz-txt-link-freetext" href="http://tools.realism.com/specification/x3d-v40">http://tools.realism.com/specification/x3d-v40</a>
<br>
<br>
<br>
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?
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
--
<br>
*Leonard Daly*
<br>
3D Systems & Cloud Consultant
<br>
X3D Co-Chair on Sabbatical
<br>
LA ACM SIGGRAPH Chair
<br>
President, Daly Realism - /Creating the Future/
<br>
</blockquote>
<br>
<br>
all the best, Don
<br>
</blockquote>
<br>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>