[x3d-public] setUSE in X3DJSAIL (note Leonard, this may affectXSeen).ImpactonX3DJSONLD.

[Leonard Daly]

Out all morning and returning to a huge stack of emails. I am responding 
to the last one with my name in the subject. I think I hit on all of the 
points, but feel free to bring up others.

I see that Andreas has responded to a few of these messages. His 
statements are correct, but I may repeat some of them just to reinforce.

DOM is an API to access the data as defined in the document (HTML, 
XHTML, XML, or other). DOM is frequently used to refer to the data 
structure that is created to support the API. I am going to try to keep 
DOM as API separate from DOM as data structure. DOM as data structure is 
a strict tree-graph in that an element (DOM version of a tag) has 
exactly one parent. The top-most element (window) parents itself. This 
does not prohibit the existence of an attribute like 'USE', but does 
restrict what it can do. It is not possible to insert the same element 
into the DOM tree in more than one location. The parent property of any 
DOM element is a reference to the element's parent. It is not a copy of 
the parent, and there is only one reference (it is not an array).

That does not eliminate the ability to use an X3D style 'USE' attribute, 
but the 'USE' nodes would not be in the DOM tree. All X3D DOM-based 
browsers maintain a separate copy of the scene graph. The 'USE' 
functionality could very well refer to the target nodes in the scene 
graph. These nodes would appear only in the DOM in the 'DEF' location. 
The 'USE' nodes would not be available via DOM methods. However, 
changing the fields of the DEF nodes should propagate into the scene 
graph. Since the 'USE' nodes are references to the 'DEF' nodes, the 
changes would appear.

After the initial parsing by the browser, the node with the 'USE' 
attribute would be in the DOM. It would be the responsibility of the X3D 
parser to correctly deal with it, including removing the specific node 
from the DOM (and not the scene graph) if that what is needed. Removing 
it from the DOM would terminate that tree branch at the 'USE' node's 
parent. An advantage of terminating it would be that would prevent DOM 
methods from trying to modify the 'USE' node. A disadvantage would be 
the loss of information and structure from the developer's perspective. 
A node that had been put in the HTML file is now not present in the DOM.

There are a couple of alternatives to removing elements from the DOM 
data structure. These would maintain a closer connection between the DOM 
data structure and the scene graph. Note that the scene graph data 
structure does not necessarily correspond 1:1 with the X3D node 
structure. A lot depends on the renderer and how it manages data and 
structure. The X3D parser is the interface between the X3D code in the 
HTML file and the necessary data structures used by the renderer to 
create the desired results. The X3D runtime is separate (at least 
logically) and manages the flow of control and data from HTML/DOM 
environment to the renderer.

One is to deep-clone the 'DEF' node and insert it at the location of the 
'USE' node. This would expand the DOM data structure to include a 
complete copy. It does mean that the X3D node branches could start to 
diverge as some operations were applied to one branch and not others.

Another alternative is to create a parent-child relationship between 
'DEF' and 'USE' nodes. This would allow 'USE' nodes to change some of 
their properties while others are controlled by the parent. This method 
would also allow a 'USE' node to become a parent for other 'USE' nodes. 
This type of subclassing is used in Unreal and (I believe) Unity. If 
this alternative is desired, I would recommend that the name (DEF/USE) 
be changed to avoid confusion.


Leonard Daly




> Additionally, if you are reading XML into DOM, like X3DJSAIL does, I 
> believe that you must create an element if you reach a USE node. If 
> you use SAX, you can do something else.
>
> Thus you would have to post-process the DOM tree to make a scenegraph.
>
> If you make your own DOM, you can do whatever you like.
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Thursday, July 20, 2017 12:18 PM
> *To: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>; 'Don Brutzman' 
> <mailto:brutzman at nps.edu>; Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Cc: *'list' <mailto:x3d-public at web3d.org>
> *Subject: *RE: setUSE in X3DJSAIL (note Leonard, this may 
> affectXSeen).ImpactonX3DJSONLD.
>
> As far as I know, there is no “parents” property on a node in DOM, so 
> this whole discussion is rather moot until that changes. If you don’t 
> have parents, then there’s no way to get to one or more of your 
> parents from a child node (not necessarily needed, but…)
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Thursday, July 20, 2017 12:11 PM
> *To: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>; 'Don Brutzman' 
> <mailto:brutzman at nps.edu>; Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Cc: *'list' <mailto:x3d-public at web3d.org>
> *Subject: *RE: setUSE in X3DJSAIL (note Leonard, this may affect 
> XSeen).ImpactonX3DJSONLD.
>
> This whole discussion of multiple referencing a node from more than 
> one parent lives squarely in the XML/DOM standardization lap.  Is 
> there any reference to it?  Can we define our own ID/IDREF attributes 
> in DOM?
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Thursday, July 20, 2017 11:46 AM
> *To: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>; 'Don Brutzman' 
> <mailto:brutzman at nps.edu>; Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Cc: *'list' <mailto:x3d-public at web3d.org>
> *Subject: *RE: setUSE in X3DJSAIL (note Leonard, this may affect 
> XSeen).Impacton X3DJSONLD.
>
> The point is, if you have a node in DOM which refers to another node, 
> they can’t have a separate list of attributes, so USE should not 
> appear anywhere in the browser, and your debugging becomes much more 
> difficult. Nuff said?
>
> But yes, if DOM integration is your goal in life, you should get rid 
> of the USE attribute when it appears.
>
> I don’t know what X3DOM or Cobweb do.
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Thursday, July 20, 2017 11:41 AM
> *To: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>; 'Don Brutzman' 
> <mailto:brutzman at nps.edu>; Leonard Daly <mailto:Leonard.Daly at realism.com>
> *Cc: *'list' <mailto:x3d-public at web3d.org>
> *Subject: *RE: setUSE in X3DJSAIL (note Leonard, this may affect 
> XSeen). Impacton X3DJSONLD.
>
> That’s all well and good, but probably requires you extend the DOM or 
> provide a DOM -> flag (this has been written) map.
>
> Currently the DOM contains the USE node as a separate object, I 
> believe (at least in X3DJSONLD, not sure about others), so everything 
> is fine, below the DOM, the scenegraph should take care not to 
> duplicate attributes.
>
> Your code below becomes:
>
>  1. Traverse the scene, stepping through each node, using depth first
>     ordering
>  2. For each node, depending on whether USE attribute is set:
>      1. If not, write out this node in full
>      2. If so, only write this node with a USE attribute.
>
> Actually, we just write out all the attributes in DOM to Java or 
> JavaScript, and thus X3DJSAIL catches the problem, I hope.
>
> If someone wants me to reuse DOM nodes in X3DJSONLD, let me know.
>
> I use standard DOM -> XML serializers, and I’m not sure how they would 
> handle it.  Poorly, I would guess. We’d probably have to write custom 
> serializers for DOM -> XML output. Which can be done!  But why 
> reinvent the wheel?
>
> I say we leave it to the scenegraph, but if someone wants real DOM 
> integration, we’ll have to go with rewriting the serializer if we want 
> XML output.
>
> Anyone want to write an XML serializer written in JavaScript for 
> X3DJSONLD that’s pluggable with my other serializers, and is hardened 
> to future DOM changes?
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>
> *Sent: *Thursday, July 20, 2017 10:29 AM
> *To: *'John Carlson' <mailto:yottzumm at gmail.com>; 'Don Brutzman' 
> <mailto:brutzman at nps.edu>
> *Cc: *'list' <mailto:x3d-public at web3d.org>
> *Subject: *RE: setUSE in X3DJSAIL
>
> Don and John,
>
> If we are talking about the step of writing our a file, then this is a 
> different question.
>
> We can use the SAI methods to query the scene in memory. Methods to 
> actually write the scene are a function of the implementation, and not 
> a formal part of the SAI. So, while an implementation may have a 
> setUSE method as part of the writing out interfaces, it is not a 
> formal SAI method. It would be appropriate to indicate, perhaps in 
> comments, those methods that are provided for the convenience of code 
> that outputs the scene to a specific encoding.
>
> For example, I could consider the following partial algorithm for 
> writing out a file:
>
>  3. Traverse the scene, stepping through each node, using depth first
>     ordering
>  4. For each node:
>      1. Check if this node has already been written
>      2. If not, write out this node in full
>      3. If so, only write this node with a USE atttrbute.
>
> Thus, this function would only write out the node type and the USE 
> attribute for step 2)c. And there would be no “resetting of values” 
> involved.
>
> All the best,
>
> Roy
>
> *From:* John Carlson [mailto:yottzumm at gmail.com]
> *Sent:* 20 July 2017 15:06
> *To:* Roy Walmsley <roy.walmsley at ntlworld.com>; 'Don Brutzman' 
> <brutzman at nps.edu>
> *Cc:* 'list' <x3d-public at web3d.org>
> *Subject:* RE: setUSE in X3DJSAIL
>
> Roy,
>
> I imagine setUSE was chosen because it was either an attribute in XML 
> or property @USE in JSON, and we were translating XML and JSON to 
> Java, Nashorn JavaScript and Python. Please provide an equivalent 
> conversion of an X3D XML file to C,C++, or C# which does not use 
> setUSE and uses SAI as you suggest. If you can do it, we will copy you.
>
> We would like to use chained methods with a minimum of extra variables 
> (ideally, just one variable for whole scenegraph will do—not currently 
> achieved). In addition, we would like to take advantage of type safety 
> as much as possible.  Please consider type safety when writing your code.
>
> There are DOM -> various languages examples you can find in 
> X3DJSONLD/src/main/node. JavaScriptSerializer.js and JavaSerializer.js 
> are good ones.  You can use any language you want, but if you 
> integrate with X3DJSONLD (json2all.js), it will be integrated into my 
> test suite.
>
> It is also possible that setUSE was required in the concrete classes 
> (not SAI that I know of) and extracting setUSE up to the interface was 
> a good idea.  I think this can be solved by providing an intermediate 
> interface.
>
> Thanks,
>
> John
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows 10
>
> *From: *Roy Walmsley <mailto:roy.walmsley at ntlworld.com>
> *Sent: *Thursday, July 20, 2017 9:13 AM
> *To: *'Don Brutzman' <mailto:brutzman at nps.edu>
> *Cc: *'John Carlson' <mailto:yottzumm at gmail.com>; 'list' 
> <mailto:x3d-public at web3d.org>
> *Subject: *setUSE in X3DJSAIL
>
> Hi Don,
>
> I note that in X3DJSAIL you have a “setUSE” method defined in all node 
> classes. I don’t see any point of having this method.
>
> My thinking is as follows. Please correct it as necessary.
>
> X3DJSAIL is meant to be an interface for an implementation of the Java 
> Language binding – ISO/IEC 19777-2.
>
> The SAI 19775-2 has no service related to “USE”. So it does not appear 
> in the Java language binding.
>
> Consider that an instance of a node (say Material) has been  loaded 
> into memory and added into a scene. Then consider that further down in 
> the scene it is desirable to implement a “USE”. What are the steps?
>
> The first would be to call the Java implementation of the SAI 
> execution context service “getNode”, with the SAIString parameter set 
> to the DEF name, and the SAIAction parameter set to DEFNode.  In the 
> standard ISO/IEC 19777-2 V3.0, clause 6.4.6 getNode the defined method 
> is getNamedNode. What is your equivalent function in X3DJSAIL?
>
> Having obtained a node reference for the DEF’d node, let’s assume you 
> also have a node reference for the node that is to be the parent of 
> the USE node, which I will assume for this example will be Appearance.
>
> You now need to obtain a reference for the “material” field of the 
> Appearance node.  We need to  use the SAI service getField, defined in 
> 6.6.4 getField in ISO/IEC 19775-2. The Java language binding lists 
> this as getField in clause 6.6.4 of ISO/IEC 19777-2. What is your 
> equivalent function in X3DJSAIL?
>
> Now that we have the field reference, and the node reference to add, 
> we can finally make a call to the SAI service setValue, defined in 
> 6.7.6 setValue in ISO/IEC 19775-2. The Java language binding lists 
> this as setValue in 6.7.6 of ISO/IEC 19777-2. What is your equivalent 
> function in X3DJSAIL?
>
> Final comments relate to garbage management. The implementation will 
> probably want some way to remember that the same node reference has 
> been used in multiple places. That is something internal to the 
> implementation, and not anything for the interface.
>
> So, in conclusion, I don’t see a need for your setUSE method. And it 
> is not in the SAI.
>
> All the best,
>
> Roy
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170720/8db88730/attachment-0001.html>