The X3D language uses mixed case node and field names. In some cases field values are specified as case-specific names. This is standard XML. HTML allows for any case and converts tags and attribute names to lower case before use. The HTML language does not impose specific case requirements on attribute values. XHTML is XML-based, so it is case sensitive; however, all tag and attribute names are defined as lowercase.

Main post that lists the major issues for integration.

The previous post ("Integrating X3D Into DOM - Inline") developed a solution for namescoped nodes, specifically Inline. This post looks at implications of that solution.

This is part of a multi-part post that explores some ideas for integrating X3D into HTML5 DOM. It explores various options and their implications. The primary post is "Integrating X3D into DOM - Issues".

HTML gained wide-spread acceptance because it was straight-forward and produced results even if you did write it perfectly - it is very forgiving. Of course, you get better results when written correctly, but you are never puzzling out what IEA102A INVALID PARAMETER/FORMAT - RESPECIFY means¹. HTML presents a unified environment to the web designer and user.

This post introduces XSeen - a declarative language built on A-Frame and X3D to achieve the desire of a fully declarative 3D/VR language that runs in the web browser. In this initial release the language supports some X3D and some A-Frame nodes and capabilities. It is possible to combine the two to produce results that are the available in either.

I attended my first Silicon Valley VR Expo last week. It was very different than VRLA. As might be expected, this one is more focused on tech; though there were plenty of content discussions. Fortunately, the expo floor was not as loud as VRLA and I had many conversations with vendors.

This is the fifth in a series discussing the next generation of X3D and addresses the needs and requirements for X3D for the display of 3D, AR, and VR content in the current ecosystem of display devices and environments. The 3D content is displaying in a larger ecosystem of including the user’s computer, browser, Internet, and originating server. As such it needs to work cooperatively within the environment and with other content already displaying in that environment.

This is the fourth in a series discussing the next generation of X3D. Archiving and long-term storage has always been a strong point of X3D. The ability to read and play content from years or even decades ago makes it unsurpassed in the 3D world. X3D has human-readable formats that can be used for archiving so that the content does not require special software to unpack and display the file contents. It is important to keep the long-term storage and access capability while along X3D to stay current with advances in display technology.

This is the third in a series discussing the next generation of X3D. The current architecture of X3D does not support the industry standards in modeling, archival, and user experience. It uses a single primary file with additional external resources loaded as needed including other X3D files or media (images, audio, video, and scripts). The capabilities made available in the X3D files are either insufficient (e.g., lack of deformable skin animation) or in conflict with the major display environment (e.g., Scripts). This post describes a systems architecture with implications for content architecture that addresses these issues.