- From: Kristian Sons <kristian.sons@dfki.de>
- Date: Mon, 22 Apr 2013 15:15:54 +0200
- To: public-d3d mlist <public-declarative3d@w3.org>
Hello, no discussion on the mailing list for some time. Thus I would like to raise a topic that seems to become more important and is strongly related to the discussion on transmission formats. We recently published a paper at SEARIS 2013 [1] that explains the architecture of xml3d.js. It's not directly related to the general Polyfill architecture that we propose in the CG but rather explains the concrete implementation of xml3d.js. It's very technical. But an interesting topic for our Dec3D discussion is the _generalized resource concept_, that we (finally) introduced in xml3d.js and that is interesting for our initiative. I think, the general tendency in XML3D as well as in X3DOM is to mix DOM representation with external data. IGD has developed some interesting transmission formats and we have a simple but powerful concept to use these (and other) formats in a generic way. Here a very simple example: 1. Intra-document references: <mesh type="triangles" src="#teapot-data"/> The data is really in the DOM and freely accessible using the DOM API or libraries such as jQuery 2. External references to a single entity: <mesh type="triangles" src="teapot.json"/> The whole mesh data set in a document, the document has no other information than the mesh data 3. External references to a structured document: <mesh type="triangles" src="primitives.xml#teapot"/> The concept is recursive, i.e. a structured document can itself contain references again. In XML3D, the concept not only works for meshes, but also for material descriptions, transformations, light parameters etc. In combination with Xflow, it allows for dynamic attributes. We have shown, that this concept can even work with more complex mesh encodings such as SIG (using smart shader compositing). This might not be too relevant for hand-crafted scenes, but is very powerful in client-server architectures, especially in a REST context. For instance, it allows to adapt the data transmission during runtime. On the other hand, if you need specialized nodes for each transmission format (IndexedFaceSet, ImageGeometry etc), one moves this logic to application level (adding/removing node instances at runtime). It fits very well to other W3C initiatives, where the composition of HTML documents from several source is becoming increasingly important. Maybe this could also be a concept for X3D 4.0? Best regards, Kristian [1] http://www.searis.net/index.php5/Main_Page -- ________________________________________________________ Kristian Sons Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realität Campus, Geb. D 3 2, Raum 0.77 66123 Saarbrücken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775–2235 kristian.sons@dfki.de http://www.xml3d.org Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ________________________________________________________
Received on Monday, 22 April 2013 13:16:26 UTC