[x3d-public] [x3d] Ideas for discussion during V4.0 Concepts: Name scopes and node name conflicts
Kristian Sons
kristian.sons at dfki.de
Fri Dec 4 03:15:05 PST 2015
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>
> Organization: Naval Postgraduate School
> To: Roy Walmsley <roy.walmsley at ntlworld.com>
> CC: X3D Graphics public mailing list <x3d-public at web3d.org>, X3D
> Graphics Working Group <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 list
> x3d-public at web3d.org
> http://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–2235
kristian.sons at dfki.de
http://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
_______________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151204/15cafdfe/attachment-0001.html>
More information about the x3d-public
mailing list