[x3d-public] browser importDocument SAI service

Joe D Williams joedwil at earthlink.net
Mon Oct 24 21:19:28 PDT 2016


>>> If a utility method filters out everything but the X3D-related 
>>> document subgraph

X3D-related may include html-style CSS? so that must be tracked down. 
Also, to get the x3d in html you may also need to capture 'external' 
animation,  sensor, and all recommended or custom DOM/SAI event 
handling scripts. Then you probably need to know the scripting 
framework, if used. So just scraping <x3d> ,,, </x3d> scene text from 
view source may not result in something that executes, and may not 
even give you smallest hint of how it might run until you find all the 
pieces.

Thanks for digging,
Joe



----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: "Leonard Daly" <Leonard.Daly at realism.com>; <x3d-public at web3d.org>
Sent: Monday, October 24, 2016 10:43 AM
Subject: Re: [x3d-public] browser importDocument SAI service


> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org 




More information about the x3d-public mailing list