<div dir="ltr">I've been looking a bit at the DFDL schema. It looks like you populate your XSD with annotations in a separate schema for each encoding you want to translate to and from. So this involves creating lots of nearly identical schemas it seems, one for each format (to/from translation with XML). So for example, one format might be FBX. Then you have OBJ. That means you need a schema for FBX and one for OBJ.<div><br></div><div>A better understanding of DFDL and its potential downsides and benefits would be appreciated before we jump into DFDL. That is, maybe instead of having a bunch of schema definition in XSD, X3DUOM, Ontology, why don't we focus on creating the best converting (animation) supporting system on the planet for 3D data.</div><div><br></div><div><a href="http://dsmforum.org/events/DSVL01/carlson.pdf">http://dsmforum.org/events/DSVL01/carlson.pdf</a> (a previous envisioning of the system <a href="https://www.computer.org/csdl/proceedings-article/wvl/1988/00018019/12OmNBp52DA">https://www.computer.org/csdl/proceedings-article/wvl/1988/00018019/12OmNBp52DA</a> which provided various visual types of field data conversion as well as a AST (abstract syntax tree) for displaying fields to convert, and a previous one to that provided for bit manipulation).</div><div><br></div><div>I envision for one, additional desktop objects for matrix and vector manipulation for X3D, bit manipulation calculators, shape creation/3D editing, etc.</div><div><br></div><div>If you haven't seen the demos of Lively Web, check them out. <a href="https://lively-next.org/">https://lively-next.org/</a> It's based on Morphic.</div><div><br></div><div>Do you see where I'm going with conversions?</div><div><br>Also look up Model Transformation by Demonstration. <a href="https://yusun.io/papers/oopsla09-sun-ds.pdf">https://yusun.io/papers/oopsla09-sun-ds.pdf</a></div><div><br></div><div>XSLbyDemo: <a href="https://ieeexplore.ieee.org/document/994471">https://ieeexplore.ieee.org/document/994471</a></div><div><br></div><div>So how can we build transformation and converters with an IDE? I don't want to use XSLT. Can we generate the XSLT with demonstrational techniques.</div><div><br></div><div>I mean, this is X3D. We should be doing data translation in a *3D* environment, perhaps? Anyone? Can we convert sign language <-> English? Why isn't there a sign language on Google translate?</div><div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 20, 2020 at 12:39 PM Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jakub and I had a useful meeting today. We looked at X3D Ontology completeness to diagnose event animation chains.<br>
<br>
A design pattern for representing animation chains is described in detail as part of the following chapter slideset. Single-page checklist also attached as a convenience.<br>
<br>
* X3D Graphics for Web Authors: Chapter 7, Event Animation Interpolation<br>
<a href="http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter07EventAnimationInterpolation.pdf" rel="noreferrer" target="_blank">http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter07EventAnimationInterpolation.pdf</a><br>
<a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/" rel="noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/</a><br>
<br>
slide 11. "Event-animation design pattern. X3D can be imposing, there are many nodes. Nevertheless a simple design pattern is used for nearly every kind of animation. his consistent event ROUTE pattern enables you to expertly animate most X3D scene behaviors."<br>
<br>
* Event-animation design pattern:<br>
Trigger node (optional) -> TimeSensor -> Interpolator/Sequencer/Script -> Target node's field<br>
<br>
A 10-step algorithm for author creation of this design pattern is provided and has proven helpful. Keeping a consistent pattern let's you avoid thinking that the various animation nodes are “really different” when they are not. It also helps you avoid skipping steps and making mistakes that are hard to debug afterwards.<br>
<br>
Example diagram also attached that illustrates the following model.<br>
<br>
* X3D Example Archives: X3D for Web Authors, Chapter 07 Event Animation Interpolation, Dolphin Morpher<br>
<a href="https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/DolphinMorpherIndex.html" rel="noreferrer" target="_blank">https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/DolphinMorpherIndex.html</a><br>
<br>
So, for X3D ontology, we want to see if we can write rules/queries to (a) illustrate event chains, and (b) diagnose whether any problems exist.<br>
<br>
Example problems:<br>
- mismatched ROUTE DEF or field-name values<br>
- mismatched data types,<br>
- mismatched accessType values,<br>
- missing pieces.<br>
<br>
So next step is to check X3D ontology for completeness of information provided. As an example, let's look at Transform in X3D Ontology. Excerpt:<br>
<br>
<a href="http://www.web3d.org/specifications/X3dOntology4.0" rel="noreferrer" target="_blank">http://www.web3d.org/specifications/X3dOntology4.0</a><br>
##################################################<br>
:Transform a owl:Class ;<br>
rdfs:subClassOf :X3DGroupingNode ;<br>
rdfs:label "Transform is a Grouping node that can contain most nodes." .<br>
# bboxCenter field inheritedFrom=X3DGroupingNode with accessType=initializeOnly, type=SFVec3f, default=0 0 0<br>
# bboxSize field inheritedFrom=X3DGroupingNode with accessType=initializeOnly, type=SFVec3f, default=-1 -1 -1, baseType=bboxSizeType<br>
:center a owl:DatatypeProperty ;<br>
rdfs:domain :Transform ;<br>
rdfs:range :SFVec3f .<br>
# children field inheritedFrom=X3DGroupingNode with accessType=inputOutput, type=MFNode<br>
# displayBBox field inheritedFrom=X3DGroupingNode with accessType=inputOutput, type=SFBool, default=false<br>
:rotation a owl:DatatypeProperty ;<br>
rdfs:domain :Transform ;<br>
rdfs:range :SFRotation .<br>
:scale a owl:DatatypeProperty ;<br>
rdfs:domain :Transform ;<br>
rdfs:range :SFVec3f .<br>
:scaleOrientation a owl:DatatypeProperty ;<br>
rdfs:domain :Transform ;<br>
rdfs:range :SFRotation .<br>
:translation a owl:DatatypeProperty ;<br>
rdfs:domain :Transform ;<br>
rdfs:range :SFVec3f.<br>
##################################################<br>
<br>
So, our prior effort was not complete. Looks like we need to come up with a proper representation for accessType and defaultValue field to achieve full expressive power in X3D Ontology that already exists in X3DUOM.<br>
<br>
rdfs:TBD1 accessType inputOutput;<br>
rdfs:TBD2 defaultValue 0;<br>
<br>
... so that is how far we got. More thinking and likely additions to to X3D Ontology will follow.<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>