[x3d-public] X3D V4 Draft Requirements Proposal

[Don Brutzman]

Leonard: thanks for your latest posts.

Key summary point you make:

On 3/27/2017 3:51 PM, Leonard Daly wrote:
> personal early draft of requirements for X3D running in a web browser environment

That seems like a good characterization.  But it does not match your subject line, nor your repeated postings on this topic.  Am hoping we can continue to improve our terms of reference.  For example, a better term is probably something like "X3D HTML5 Encodings" or "X3D HTML5 Profile" or simply "X3D in HTML5" to make the scope of your objectives clear.

A lot of work has been performed over many years (23 actually) with several years recent effort on X3D v4.  The consensus list of goals and capabilities to date remains at

	X3D Version 4
	http://www.web3d.org/x3d4

	X3D version 4.0 Development
	http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

It's not clear that much much recent dialog is penetrating several portions of your list.  For example, SVG also has a script node that seems to operate just fine in combination with HTML.  It seems prudent to pose interoperability as the baseline goal requirement, with the corresponding due diligence to compare pros/cons and implement alternatives.  Listing things like "nodes shall not have name conflicts" and "shall behave as the HTML element" as end states seems to close off such necessary consideration of alternative approaches that already exist and can work.

Additionally, the informative references you list are helpful but the W3C Recommendations for HTML remain the authoritative versions that we are designing to align with.  We must be very precise about these concepts.  For example, rather than just saying "events" we need to distinguish between DOM events and ROUTEd X3D events.  Perhaps we need some kind of a glossary list to help avoid ambiguous terminology.

The good ideas in your lists will certainly help further if we can correlate them with known strengths, capabilities and challenges that are found in the existing spec + design goals for X3D.

It is also important to remember that the whole point of a standard is stability - which is not the same as stasis.  We have carefully evolved X3D in many ways and continue to improve it without breaking legacy content.  Change is certainly possible and expected, but improvements and refinements need to be fully thought through.  When architectural changes are pursued, we also have to show how prior content can be upgraded or converted compatibly.

The many efforts of working group participants (yourself included) on Mantis issues, version-control specifications, comprehensive object model, validatable examples and stable implementations have us well positioned to follow through with complete success on X3D v4.

A bit of wisdom from one insightful individual early in our VRML specification process pointed out that standards are typically compromises among what we want, what we must have, what we can live with, and what we can't live with.  The path to building consensus examines those tradeoffs realistically through comparison, dialog, implementation and evaluation.

We have more assets and capabilities and demonstrated knowledge than ever before.  It's an exciting time to work on X3D!  Thanks for listening and sharing, looking forward to further progress for everyone together.

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