[x3d-public] browser importDocument SAI service

[Don Brutzman]

Summary: DOM disambiguation of script elements within HTML documents that also contain X3D scenes.

On 10/24/2016 9:13 AM, Leonard Daly wrote:
> On 10/24/2016 8:23 AM, Don Brutzman wrote:
>> On 10/23/2016 8:18 PM, Leonard Daly wrote:
>>> On 10/23/2016 2:35 PM, Don Brutzman wrote:
>>>> On 10/22/2016 8:35 PM, Andreas Plesch wrote:
>>>>> On Oct 22, 2016 6:27 PM, "Don Brutzman" <brutzman at nps.edu> wrote:
>>>
>>>>>> - loading HTML that contains embedded X3D scene
>>>>>
>>>>> parsing HTML into a DOM is very available. I am not quite sure what scenario you would have in mind here.
>>>>
>>>> something like
>>>>
>>>>     http://www.web3d.org/x3d/content/examples/HelloWorldCobweb.html
>>>> or
>>>>     http://www.web3d.org/x3d/content/examples/HelloWorldX3dom.xhtml
>>>>
>>>> in other words, an HTML document that contains an X3D scene, should we have a utility method that loads the document but strips out any HTML/CSS/etc. and leaves only X3D scene
>>>
>>> This is potentially risky because JavaScript can modify or even create the HTML as the file is loading to produce different results. Some HTML frameworks (e.g., React.js) load partial content until the region to be display is nearly visible to the user, then the entire region is loaded. The scene may also contain some vendor-specific scene elements that should not be filtered out.
>>>
>>> It is probably much easier (and safer) if you only accept straight X3D than start mandating that the embedded X3D in HTML follow some very specific design constraints.
>>
>> Security issues are certainly always worth considering.
>
> Security is potentially an issue. I was thinking of something much more just related to content.
>
> Consider the following HTML code snippet
>
>
> <script>
> document.writeln ('<X3D id="x3d_scene" ...>');
> </script>
>     <Scene>
>         <Transform>...</Transform>
>             :
>             :
>     </Scene>
> </X3D>
>
>
> Without the part in the script, there the opening X3D tag is missing; however, a browser would handle this correctly.

The fragment above is missing <X3D> and so nothing would be found.

Once that is added, the <script> is html and would be filtered by such a utility method.

When walking the DOM tree, the document.writeln contents would be ignored since it is all simply a string within that node.

Disambiguation of HTML and X3D script elements is still something to be handled in such a filter.
a. Of course putting HTML scripts inside an X3D scene (and vice versa) is probably not a very good practice.  So there is a default disambiguation that works:  determine what kind of script is encountered by first ancestor, HTML or X3D element.
b. Second potential disambiguation of scripts: presence of default attribute containerField='children', or presence of child <field> elements indicates an X3D Script.  (Majority of X3D Scripts have both.)
c. Third potential disambiguation of scripts: look for presence of HTML attributes.
d. Other techniques can be figured out if actually needed.

> Another case: Someone is developing a new node -- StereoViewpoint. If the extractor program knew X3D nodes, then StereoViewpoint would not be identified as such. If the extractor program did not know about X3D nodes but took everything between <x3d> and </x3d>, then any non-X3D nodes (e.g. HTML elements) would be included.

Invalid X3D is invalid X3D - GIGO.

Even so, strict validation of scenes or scene fragments is optional for any codebase.  Typically programmatic approaches avoid such validation, or defer it to completion, since validation errors that occur during scene construction are interruptive and unhelpful.

The Java SAI library I'm constructing uses strong typing throughout so that most value-mismatch errors are detected prior to successful compilation.  It also throws an exception if an invalid value is applied to a field at run time, since always better to know where an error occurs than to wonder why something is mysteriously failing.

Alternative for a StereoViewpoint extension: Prototypes can also work.

> My point being that requiring a capability to store X3D nodes in an HTML document is creating a very difficult and perhaps unsolvable requirement.

No such requirement was suggested.  Rather a utility method technique was suggested.  Hopefully that approach now seems more do-able.

> For an analogy, you don't see HTML embedded in JPEGs.

Actually .JPG, .TIF, .WAV files can contain metadata.  For example, see Exchangeable image file format (officially Exif).

	https://en.wikipedia.org/wiki/Exif

>> Any DOM-tree document is subject to prior modification before loading.
>>
>> Importing a DOM document is not a live self-modifying object at time of import, rather it is simply the string data contained in the DOM element/attribute tree.
>>
>> If a utility method filters out everything but the X3D-related document subgraph within an HTML document graph, the security issues would seem to be the same as importing an X3D document in the first place.

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