Re: request for guidance: centralized extensibility for HTML5 using X3D graphics

> * As a HTML implementor, I would like to see X3D mature a bit more 
> in the web world before committing to implementing this. 3D on the 
> web is still very new technology, especially in the form of markup. 
> It's very hard for me to judge how likely it is that X3D is the 
> solution that we'll want to go with.

Hi Jonas,
Thanks for your interest in WWW 3D and in particular, X3D. Actually 
the history of 3D data markup is nearly as long as for text data 
markup. VRML1 served as a formalized, ISO, best practices 
interchange/intermediate format to transport geometry and lightning 
for many years. VRML2 (VRML97) brought the scene and event graphs to 
life in the same way as the DOM brought breath to HTML. As XML 
evolved, VRML3 (VRML2002?)  made the 100% lossless transition to X3D, 
which offers advanced XML dtd/schema, source code as UTF-8 using 
either XML or Classic encodings, and an advanced XML standards-track 
binary.

Bringing realtime 3D to the WWW via html5 has two main objectives. 
First, to produce a common standardized plugin interface to the html 
document, with main focus on <object> and <embed> elements. This 
allows X3D plugin builders to produce X3D OGL//OCL/Dx plugins so that 
authors and users actually have the choice of several mostly 
equivalent active objects for use in extending the basic interfaces of 
the html web page. I think this is real important because getting this 
done has proven to be not that easy (although certainly improving). As 
with many web problems, there is a path around the blockage. If html 
is having trouble figuring out how to allow powerful plugins, then 
path is easier for a 'plugin' to just run freestanding. For instance, 
it may be easier for an X3D  'plugin' to host an active instance of 
one of various html web browsers to provide part of the show than it 
is to get an X3D plugin hosted consistently in the various html 
browsers. So, consistent installation, registration, instantiation, 
and interactivity with the DOM, and other host services are essentials 
if an author wishes to host a live X3D scene context in the document.

Second (and already happening before our very eyes in experimental 
form), how about elements of X3D used as 'native' code blocks 
intermingled with HTML5. In this case we are talking about encoding a 
scene as <x3d>... </x3d> in the same way as elements like <table>, 
<svg>, <mathml>, <ruby> are incorporated into html5. Best fortune has 
provided a powerful testbed for this concept. It turns out that a 
WebGL/O3D layer can easily support either a 'builtin' ecmascript 
processing of X3D user code. as well as a 'bulitin plugin' to any of a 
couple of very powerful X3D scene/event graph processors for heavier 
work in complex interactive visualizations.

Practically any past history of 3D on the WWW gets updated by a giant 
step just looking at www.x3dom.org. Dr. Behr has provided these 
examples just in case anyone wanted to compare X3D with any other 
forms of encoding various themes showing declarative realtime 3D 
shapes, lighting, navigation, and interactivity, including 'internal' 
ecmascript. Essentially, the technique used for reading and rendering 
X3D could be done for any syntax, so most anyone interested in 
learning about 3D can pick anywhere they wish to start. I would say to 
just go ahead and start with X3D because nothing you learn about basic 
3D stuff and h-anim is likely to be past history anytime soon. 
Besides, most any 3D vendor will export X3D. LIkewise, most any X3D 
tool chain will import Collada, KML, CitiML, and many others. And 
really, it is no harder to hand edit X3D element structures than 
HTML5.

But showing X3D working in the <canvas> rig, or as 'native' html/xhtml 
markup with (free)DOM element scripting, still does not totally 
demonstrate that four or nine html5 web browsers can eventually all 
incorporate the syntax in a way that avoids the need to post a 'works 
best in ...' warning to our users. However, lots of the hard work has 
been done. X3D has an XML Schema namespace as well as just happening 
that no other candidate html 'native' keyword conflicts. Many of the 
of the opportunites found in the integration of SVG into HTML5 will be 
leveraged into the integration of X3D.

Ooops, just noticed I have a holiday. Please take a closer look at 
x3dom.org, I'm using minefield now with fine results.

Thanks for all your interest and Best Regards,
Joe

http://khronos.org/webgl/wiki/User_Contributions#Learning_WebGL
http://web3d.org/x3d/wiki/index.php/X3D_and_HTML5
http://web3d.org/specifications/x3d-3.2.xsd
http://jonpeddie.com/media/the_history_of_3d_in_computers/
 .


----- Original Message ----- 
From: "Jonas Sicking" <jonas@sicking.cc>
To: "Paul Cotton" <Paul.Cotton@microsoft.com>
Cc: "Don Brutzman" <brutzman@nps.edu>; "Sam Ruby" 
<rubys@intertwingly.net>; "Maciej Stachowiak" <mjs@apple.com>; "J. A. 
Stewart" <alex.stewart@crc.ca>; "Johannes Behr" 
<johannes.behr@igd.fraunhofer.de>; "Joe D Williams" 
<joedwil@earthlink.net>; <public-html@w3.org>; "Noah Mendelsohn" 
<noah_mendelsohn@us.ibm.com>; "Henry S. Thompson" <ht@inf.ed.ac.uk>; 
"Tony Ross" <tross@microsoft.com>
Sent: Friday, February 12, 2010 2:58 PM
Subject: Re: request for guidance: centralized extensibility for HTML5 
using X3D graphics


Though personally, I would prefer to see X3D integration done as a
separate spec, similar to RDFa+HTML and Microdata. There are a couple
of reasons for this:

* HTML5 is reasonably stable currently. Most changes that happen are
editorial. I'm concerned that integrating X3D would set back the
release schedule for the HTML5 spec.
* As a HTML implementor, I would like to see X3D mature a bit more in
the web world before committing to implementing this. 3D on the web is
still very new technology, especially in the form of markup. It's very
hard for me to judge how likely it is that X3D is the solution that
we'll want to go with.

This doesn't need to make any technical difference. The normative
requirements can be exactly the same with X3D as a separate spec, as
for X3D being part of HTML5. The difference is just an editorial one.

I'm sure there are others that disagree, but I wanted to get my
opinion on the record.

I am however happy to let the HTML WG take on such a work item.

/ Jonas


On Fri, Feb 12, 2010 at 2:38 PM, Paul Cotton 
<Paul.Cotton@microsoft.com> wrote:
>> Should this be raised as an ISSUE?
>
> Please refer to the WGs decision policy at 
> http://dev.w3.org/html5/decision-policy/decision-policy.html If you 
> want a change made to the HTML5 specification then you should 
> initially follow the Basic Process described at 
> http://dev.w3.org/html5/decision-policy/decision-policy.html#basic
>
> /paulc
>
> Paul Cotton, Microsoft Canada
> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
> Tel: (425) 705-9596 Fax: (425) 936-7329
>
>
> -----Original Message-----
> From: Don Brutzman [mailto:brutzman@nps.edu]
> Sent: Friday, February 12, 2010 4:03 PM
> To: Sam Ruby; Paul Cotton; Maciej Stachowiak
> Cc: J. A. Stewart; Johannes Behr; Joe D Williams; 
> public-html@w3.org; 'Noah Mendelsohn'; Henry S. Thompson; Jonas 
> Sicking; Tony Ross
> Subject: request for guidance: centralized extensibility for HTML5 
> using X3D graphics
>
> [Dear HTML5 chairs: guidance requested. Other responses welcome too,
> cc: includes public-html and TPAC 2009 special-session participants]
>
> Sam, Maciej, Paul:
>
> In response to the November 2009 TPAC meeting's plenary debate, an
> HTML5 working group presentation and subsequent guidance 
> discussions,
> the X3D working group has produced a detailed response describing
> how X3D can be part of HTML5 in support of centralized 
> extensibility,
> similar to SVG and MathML.
>
> The response document _HTML5 Recommendation Additions for X3D_ is 
> online at
> http://www.web3d.org/x3d/content/html5/HTML5RecommendationAdditionsForX3D.html
>
> Some comments and amplifying information are available at
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238
> http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5
>
> A javascript-based X3D player invokable from HTML content has been
> produced to demonstrate how these capabilities can work together
> closely. It utilizes the WebGL layer provided in Minefield/Firefox
> and Webkit/Safari/Chrome nightly builds, and also shows excellent
> performance results. Available at http://x3dom.org
>
> We are also prepared to extend these leading browser implementations
> to add open-source solutions for native UA rendering of X3D scenes
> within compound HTML5+X3D documents. Details at
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238#c26
>
> Minutes from the Decentralized Extensibility in HTML5 session at
> TPAC 2009 online at following address, have also cc:ed participants
> http://www.w3.org/2009/11/04-tpac-minutes#item02
>
> So what's next?
>
> Should the HTML5 working group choose to not proceed farther than
> SVG and MathML with centralized extensibility, we remain interested
> in showing proper decentralized extensibility for X3D in HTML5. 
> Again,
> guidance regarding best practice would be needed from HTML5 group.
>
> Thus we now are seeking guidance regarding how to best proceed. 
> There
> has been little discussion of our proposal on the HTML5 list. Should
> this be raised as an ISSUE? Would you like us available on one or 
> more
> weekly teleconferences, or private discussions? We are standing by.
>
> Thanks for your many efforts and for considering this formal 
> request.
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu
> Watkins 270 MOVES Institute, Monterey CA 93943-5000 USA work 
> +1.831.656.2149
> X3D, virtual worlds, underwater robots, XMSF 
> http://web.nps.navy.mil/~brutzman
>
>
>

Received on Monday, 15 February 2010 19:06:47 UTC