[x3d-public] browser importDocument SAI service

Don Brutzman brutzman at nps.edu
Sun Oct 23 14:35:58 PDT 2016


On 10/22/2016 8:35 PM, Andreas Plesch wrote:
> On Oct 22, 2016 6:27 PM, "Don Brutzman" <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>> [...]
>> Open issues and possibilities:
>>
>> - loading scene fragments
>
> While the spec. mentions document fragments as a dom argument for importDocument, it does not say if the dom to be imported can be an incomplete scene or scene fragment, similar to createX3DfromString.
>
> I was expecting a createX3DfromDOM service but importDocument may have been intended to fill this role.

Yes likely.  With other X3D encodings also available, we'll need to look at coherent/consistent naming for all such SAI methods.

> Using the XML encoding most x3d statements are obvious in how they are derived from a DOM although strictly speaking in the HTML DOM all x3d nodes are HTMLUnknownElements. Script is perhaps the only node which may need specific treatment in an importDocument or createX3DfromDOM spec.

interesting observation!

>> - 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?

>> - loading Shape Resource Container (SRC) model
>
> Or glTF ? X3dom just got support for that. It has ExternalGeometry and ExternalShape nodes for this purpose.

That certainly sounds like something to consider, and may constructively influence the mesh discussions.

>> - loading importer results (again X3D scenes or scene fragments)
>
> I think currently the SAI only expects root nodes to be added to an existing scene from importer results, eg. imported scene root nodes. On the other hand, the SAIScene created by createX3DfromString is used in scripts as a way to add field values anywhere from what I have seen.
>
>> am thinking about how X3D Schematron, X3D Validator and X3D Tidy might handle these kinds of cases.
>
> What do you have in mind ? Looking inside the resources to be imported ?

"yes" for each of these: the ability to filter-out non-X3D elements, and the ability to load X3D scene fragments (rather than only entire documents).

>> Perhaps they should be SAI utility methods as well, at least informal additions in implementations for experimentation.
>
> Currently, it is convenient for cobweb_dom if not necessary to use internal cobweb non-SAI methods to deal with adding nodes as field values somewhere in the scene graph. There may be room for such SAI utility methods.

good - we can work on similar signatures/semantics for such added utility methods.

the more we build out similarities in commonly used codebases, the more programmers will be encouraged to directly manipulate X3D.

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



More information about the x3d-public mailing list