[x3d-public] [x3d] Ideas for discussion during V4.0 Concepts: Name scopes and node name conflicts

John Carlson yottzumm at gmail.com
Fri Dec 4 05:59:30 PST 2015 

Archival yet vibrant and relevant?  Books and microfiche are archival.
What's important is being able to take the vibrant and relevant stuff and
convert it to archival format in a mostly lossless fashion.

I can't even get something with random motion, prototypes and shaders
working together on a mac, so...  I can get shaders working in x3dom, vrml
scripting and prototypes working in x3d (instant player).   And then I want
to throw random Geo motion in on top of that (bubbles following you around
in the wind as you swoop around the earth)?  Perhaps X3D or I have too big
of bite.  I've been thinking about how to implement application (not
content--constraining the user like a game or physics might) security as
well...

Suggestions for a mac player are welcome.  Does all the above work together
on pcs?  I have x3dom, cobweb, instant player, freewrl, xj3d, and even bs
contact, if I care to open safari.  I think the point is that windows/the
desktop is lessening in relevance and this has left people scrambling.
Let's see X3D-Edit on mobile RSN.
Michael, X3D community,

I think you raise some very good and valid points here. X3D is at a point
where patchwork solutions will not be enough to remain relevant. Hence in
my opinion its not just about nodes and encodings that need to be
re-considered, but also some of the fundamental concepts.

I hope that this discussion (I tried to encourage as well with my mail) has
not died but is continued on the member mailing list.

Best,
  Kristian

Being not a deeply technical computer graphics person, but being a member
of the Board as a Professional Member representative, I wanted to voice my
opinion regarding the direction of X3D 4.0 as I interpret it from Don's
post below.

To remain a viable and robust 3D standard for years to come, and to in fact
be an archival 3D standard, X3D must remain relevant.  When I say relevant,
that means to be easy to understand, to take advantage of current
technology trends and to be widely adopted.  Whereas X3D has weathered many
ups and downs in the 3D industry over the past 25 years, outlasting
numerous 3D files formats and initiatives, it is a completely different
environment now.

The democratization of 3D content is upon us, fueled by decades of video
game technology providing the impetus for better and better software tools,
higher and higher performance graphics hardware, and a culture that now
demands 3D experiences both within and without of the video gaming
experience.  These forces have permeated the mobile industry, which is
rapidly becoming the hardware platform of choice.  WebGL has enabled 3D
within browsers without a plugin, making the browser an ideal distribution
vehicle for 3D data and content, regardless of the device.  Soon all mobile
devices will be 3D content generators, thanks to built in 3D cameras, and
virtual reality displays, thanks to Cardboard and GearVR (and others to
come).

In my opinion, X3D cannot wait out the 3D storm this time, because forces
influencing this industry are going to fundamentally change how 3D fits
into society, (think 3D printing, VR videos, etc.).   X3D must adapt to
meet this change, and with the web being the ideal distribution vehicle,
X3D must adapt to the HTML environment.  Don's post to me speaks instead to
a stay the course strategy, maintaining paradigms in contradistinction to
HTML.  There are key concepts in X3D which clash with HTML, and if not
reconciled, this will be to X3D's detriment and potential road to
irrelevance.  Why?  Simple: Compare the number of web developers to the
number of X3D developers; the difference is several orders of magnitude!
This is the target audience of X3D, and they will not tolerate learning 2
different ways to do many of the functions necessary to create a dynamic 3D
environment.  Some may say that different vertical industries will create
their own proprietary applications and that web development is irrelevant,
and I argue that while that is true, the volume and value of those
applications pale in comparison to web applications within any industry.
Being part of one of the biggest vertical industries (healthcare) as an IT
executive, I can tell you that off-the-shelf technology based on the
web/cloud is the preferred choice.  Web applications are easier to
maintain, easier to implement and easier to have personnel trained on their
use.

Many may argue that this approach can endanger backwards compatibility,
which is critically important for an *archival* standard, but to that I say
that members of the Consortium are very smart and capable of doing things
that people say never could happen, like having polygons and voxels living
together (gasp!) in the same scene.  They can develop converters for old
content so that 20 year old content still runs on the newest browsers.

Many may say that web developers aren't our target audience, which to that
I say, are you interested in protecting some academic institutions and a
small portion of industrial applications from from vendor lock-in, or do
you want to protect the majority of content developers, consumers and the
majority of industrial applications from this lock-in (whose savings would
then be passed on to the consumer)?  I choose the latter.

The way forward does not lack suggestions: Leonard Daly has done a
significant amount of thinking and work on providing a vision of a possible
X3D 4.0 that blends well with HTML concepts, Tony Parisi has developed
GLAM, another "declarative language for creating 3D web content" and
Kristian Sons' post on November 26 with subject: "XML3D 5.0 and X3D V4.0"
(XML3D being another declarative 3D web language) provides great lessons
learned on some ways that X3D can adapt HTML concepts.  The Consortium can
co-opt all the best from these suggestions to provide a phenomenal 3D
standard for the future.

I have been involved in some form with the Consortium for 20 years, from
the VeRGe meetups organized by Linda Jacobson and Timothy Childs in the
90s, to founding a startup using VRML technology in 2000, to representing
the Consortium at SIGGRAPH and Professional Members on the Board for the
last several years.  I want the Consortium to succeed in its original
mission to provide an open, ISO ratified, royalty free, archival standard
that is like an HTML for 3D on the web.  To achieve that mission, the
Consortium needs to make X3D a web native language.

Thank you,

Michael Aratow, MD
Board of Directors, Web3D Consortium
Chief Medical Information Officer, San Mateo Medical Center
CEO, VRecover







Subject: Re: [x3d-public] [x3d] Ideas for discussion during V4.0 Concepts:
Name scopes and node name conflicts Date: Wed, 18 Nov 2015 09:28:26 -0800 From:
Don Brutzman <brutzman at nps.edu> <brutzman at nps.edu> Organization: Naval
Postgraduate School To: Roy Walmsley <roy.walmsley at ntlworld.com>
<roy.walmsley at ntlworld.com> CC: X3D Graphics public mailing list
<x3d-public at web3d.org> <x3d-public at web3d.org> <x3d-public at web3d.org>, X3D
Graphics Working Group <x3d at web3d.org> <x3d at web3d.org>


[cc: x3d-public]

Thanks for the excellent leading questions and deep exploration in today's
X3D working group teleconference.

Questions and my first-cut responses follow.

On 11/18/2015 2:40 AM, Roy Walmsley wrote:
> Some things to consider and/or discuss re X3D V4.0 during X3D WG meeting.
>
> ·What is DOM?

DOM is the simplest possible API for accessing and traversing an HTML/XML
tree structure, with accessors typically getting/setting nodes and
attributes using string values.

DOM also includes several event models that are associated with navigating
a tree, and passing values from one node to another.

DOM bindings have been formally specified for JavaScript and Java.  No
doubt a number of libraries exist in other languages as well.

The essential stability of the data structures, and the potential
flexibility of the event-passing mechanisms, are the key to DOM's
long-running stability, popularity and effectiveness.

> ·What specification(s) should we be normatively considering? (
http://www.w3.org/TR)

DOM level 3 has been a stable W3C Recommendation for 10 years
http://www.w3.org/TR/DOM-Level-3-Core

DOM behavior is central to HTML5 design.

3 Semantics, structure, and APIs of HTML documents
http://www.w3.org/TR/html5/dom.html#dom

DOM level 4 is where DOM refinements are heading.  The editors include
critical individuals in this long evolution.  Based on current status, it
is pretty far down the W3C Process towards final approval.

W3C DOM4, W3C Proposed Recommendation 6 October 2015
http://www.w3.org/TR/dom/

An important working document, but not normative, is the "DOM Living
Standard" by the whatwg
https://dom.spec.whatwg.org

Of course "living" standard/document is a euphemism that actually means
"unstable" or "nonstandard."

I believe our strategy should be:

a. Let HTML5 be HTML5 and let X3D be X3D.  Each is well defined.
b. Let X3D v4 add minimal general capabilities that provide a clean elegant
stable alignment with HTML5 and DOM level 4.
c. The essence of this alignment is event passing between HTML5 DOM and X3D
event graph.
d. Do not add any functionality to X3D that breaks the current event model,
or might have to change in the future when further DOM embellishments occur.

Suggest that the next question to explore is:

- What is SAI?  What are differences between "internal" and "external" SAI?

In short, SAI reconciled internal event passing and external event passing
with the series of X3D API specifications.

No longer needed:  External Authoring Interface (EAI).  Nevertheless
interesting (and possibly helpful) approaches were specified there.

> ·How does DOM compare to SAI? (
http://www.w3.org/TR/DOM-Level-3-Core/introduction.html and
http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/concepts.html#General).
Are they conceptually different?

Comparing/contrasting each of these approaches with DOM APIs for tree
manipulations and event passing will be fruitful.

X3DOM (and presumably Cobweb) provide existence proofs that event passing
between each is possible and can be pretty simple.

Key X3D constructs:  ROUTEs, Inline IMPORT/EXPORT.

Also important parts of event-model review (identified by Joe) are Script
directOut functionality, the notion of a render frame (time step) and event
cascades, loop-breaking rule, etc.

Since many events between X3D and DOM will be related to user interaction,
closely aligned topics are javascript callbacks, browser render loops, etc.
etc.

Our eventual X3D v4 specification solution will define DOM constructs with
equivalent 2-way functionality.

>  Should SAI be renamed / substituted by DOM?

No.  Such a change would likely break X3D event semantics, either now or in
the future.  That outcome is not acceptable.

Comparisons between SAI, EAI and DOM will let us assess what needs to be
specified to align X3D and DOM.

> ·What does the DOM say about namespaces? How have MathML and SVG been
incorporated?
>
> ·Can we point to examples that illustrate difficulties?
>
> ·What practical steps should we take to progress?

Worthy questions deserving further elaboration.  We need to include CSS and
Javascript in that review as well.

If/when we do this correctly, X3D rises to the level of being an effective
addition that integrates well within the Open Web Platform (OWP).
http://www.w3.org/wiki/Open_Web_Platform

Precise terminology and descriptions are critical ingredients for effective
design.  Thanks for all due diligence on these central topics.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org



_______________________________________________
x3d-public mailing
listx3d-public at web3d.orghttp://web3d.org/mailman/listinfo/x3d-public_web3d.org



-- 
_______________________________________________________________________________

Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany

Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax:   +49 681 85775–2235kristian.sons at dfki.dehttp://www.xml3d.org

Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
_______________________________________________________________________________


_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151204/c493e33a/attachment-0001.html>

More information about the x3d-public mailing list