[x3d-public] Inconsistencies in Requirement

Sun Jun 18 11:26:50 PDT 2017

>
> Date: Sun, 18 Jun 2017 10:18:16 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
> Subject: [x3d-public] Inconsistencies in Requirements [was: Validation
>         improvements for "USE" attribute]
> Message-ID: <9364121c-2f7c-e998-da78-27808d24a8d8 at realism.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> I read the message below yesterday and I don't see how it answers the
> issue of USE statements. Perhaps it is my lack of understanding of
> something here. Can it the answer please be restated. To help things
> along I am summarizing my points.
>
> 1) The X3D specification requires nodes to have more than one parent in
> the case of DEF/USE
>

> 2) For V4, there are statements that all X3D nodes will be in the DOM.
>

I saw also a statement that there could be a parallel tree approach, such
as x3dom and cobweb_dom employ.

It may be also instructive to determine how x3dom currently deals with
DEF/USE. My recollection is that DOM elements with a USE attribute have
just one parent (they have to) but are mapped to x3dom nodes (in javascript
memory) which have the DEF parent (through a map).

cobweb_dom is initally loading nodes including USE nodes with the SAI
importDocument(DomNode) function (
http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject)
. USE nodes added later to the DOM are parsed into the x3d graph using
cobwebs parser which I think takes care of parenting to the x3d DEF node.

A-frame has an assets systems which allows reuse of components in multiple
entities. I suspect A-frame avoids copying and would reference the same
asset multiple times. This is possible because A-frame also has a parallel
scene graph (the THREE graph) which exists in memory apart from the DOM.

Another angle is the shadow DOM but I am not sure if that applies since I
suspect that it also does not allow multiple parents.

I think SVG has DEF/USE as well. SVG then must define some exceptions (?).

Overall, it looks like it may be necessary to rely on more than the DOM
alone for DEF/USE functionality.

some thoughts, Andreas

3) For V4, there are statements that it will be backward compatible (as
> much as possible)
> 4) The DOM specification prohibits nodes with more than one parent.
>
> It is not possible for Web3D Consortium to change the DOM specification
> (though it is possible to petition for a change). It is possible to
> change the X3D specification (1). It is also possible to relax the
> statements in (2) and (3).
>
> There are inconsistent requirements if DEF/USE means a reference to the
> DEF node and all nodes are in the DOM.
> There are consistent requirements if DEF/USE means a copy of the node
> tree originating at the DEF node (drop #1&3)
> There are consistent requirements if not all X3D nodes are in the DOM
> (drop #2)
>
> I would be interested in hearing anyone else's ideas on how the
> inconsistencies in existing statements and specifications can be resolved.
>
> Leonard Daly
>
>
> P.S. regarding 'class' and USE. Going strictly by the X3D
> specifications, it makes no sense to allow 'class' in a node as the USE
> attribute indicates that what appears in this position in the scene
> graph is a reference to a node defined elsewhere. There is no provision
> for this DEF node to be anything other than a reference.
>
>
>
> > Primary is getting to clarity on best possible USE definition for X3D
> > per se.  We discussed Thursday on spec teleconference.
> >
> > It would seem that allowing different 'class' attributes on USE in the
> > XML Encoding is over-generous and should be tightened to not be
> > allowed.  We were able to come up with examples that showed diverse
> > class+USE is problematic (e.g. cannot style a Material node to be a
> > class='somethingBlue' while styling a USE version of the same node to
> > be class='somethingRed').
> >
> > Next will be considering if 'class' attribute can be advanced to
> > abstract spec and hence all encodings; currently it is only
> > reserved/defined in XML Encoding.
> >
> > Regarding DOM tree and X3D tree, they do not have to be considered as
> > necessarily identical all of the time.  If event models are decoupled
> > and handing off in tandem, then synchronization would occur after each
> > respective update.  There are different ways for implementations to
> > accomplish this - all worth considering, with HTML5/DOM
> > Recommendations being authoritative regarding functionality.
> >
> > So, step by step.  If we can define semantics that work
> > consistently/coherently, and can be implemented, we then refine
> > iteratively for use in each X3D encoding.
> >
> >
> >
> > On 6/15/2017 10:58 AM, Leonard Daly wrote:
> >> The original purpose (and still used in this manner) of the 'USE'
> >> attribute is to indicate that another node should also appear in
> >> place of the node declaring 'USE'. In fact the specification states
> >> (4.4.3 -
> >> http://www.web3d.org/documents/specifications/
> 19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics)
> >> that "the same node is inserted into the scene graph a second time,
> >> resulting in the node having multiple parents".
> >>
> >> This requirement is not allowed in DOM (see
> >> https://www.w3.org/TR/dom/#concept-node-tree for the standard,
> >> https://www.w3.org/wiki/Traversing_the_DOM#Nodes for the
> >> explanation). A DOM element is allowed to have at most one parent. It
> >> is possible to create a (deep) copy of the node and insert it into
> >> the tree. That gives a structure like:
> >>
> >> [Meant to be seen in fixed width font]
> >>
> >>    B - C - D
> >> /
> >> A
> >>   \
> >>     E -CC -DD
> >>
> >> Where A is the parent of this (sub-)tree, B is the node that start
> >> one branch (e.g., Transform). C is the 'DEF'ed node with a child of
> >> D. E is a separate child of A (e.g., a different Transform) CC is the
> >> 'USE' version of C. Since HTML does not allow multiple parents ('B'
> >> and 'E'), a copy of 'C' needs to be made. This needs to be a deep
> >> copy (all children) as no node can have more than one parent.
> >>
> >> The problem with a deep copy is that it is non-deterministic as the
> >> element is self-referential (it refers to it's parent, which refers
> >> to it...)
> >>
> >> It seems to me that there is a conflict in requirements between X3D's
> >> statement on DEF/USE and the requirement to put all X3D nodes in the
> >> DOM. There are several ways around this:
> >> 1) Remove the multiple parent requirement from DEF/USE
> >> 2) Remove the requirement of all nodes being in the DOM.
> >>
> >> Each has advantages and disadvantages. Which choice is made
> >> determines how X3D operates in the HTML/DOM environment.
> >>
> >>
> >> Leonard Daly
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> Hi all,
> >>>
> >>> Recently we updated the DTD/schemas to make the ?name? field of
> >>> nodes like MetadataBoolean, or FloatVertexAttribute a required
> >>> field. However, we then realised that when any of these nodes has
> >>> the ?USE? attribute, the ?name? field must not be set. Hence the
> >>> changes needed to be revisited.
> >>>
> >>> I started to look at the JSON schema for the MetadataBoolean node,
> >>> to try to implement this stricter validation requirement. With some
> >>> online assistance I found that I could easily make either one or the
> >>> other required, but not both. This would meet the original requirement.
> >>>
> >>> However, this raised a more general question in my mind. When any
> >>> node has the ?USE? attribute set, what other fields/attributes are
> >>> permitted?
> >>>
> >>> As a test case, I concentrated on the MetadataBoolean node. I came
> >>> up with a JSON schema that might illustrate this better. I have
> >>> attached a snapshot image for this fragment of the JSON schema.
> >>>
> >>> The validation of the MetadataBoolean node begins with a ?one of?
> >>> operator (shown immediately to the right of the MetadataBoolean box.
> >>> This operator requires that one, and only one, of the two subschemas
> >>> be valid. For the first subschema (the upper of the two) I simply
> >>> removed the ?@USE? property, making the ?@name? field required (to
> >>> meet the original requirement). For the second subschema (the lower
> >>> of the two) I made the ?@USE? property required, and only added the
> >>> ?IS? property. Note that both subschemas only permit those
> >>> properties listed (i.e. additional properties are disallowed).
> >>>
> >>> In principle, there should be no difficulty applying this validation
> >>> methodology within the JSON schema to all nodes.
> >>>
> >>> Some questions:
> >>>
> >>>  1. Is this validation methodology correctly aligned with the
> >>> standards?
> >>>  2. Do we want to apply this methodology to all nodes?
> >>>  3. Do we want to apply this methodology to other validation tools,
> >>> e.g. Schematron, and also consider whether the XML schema or the DTD
> >>> have sufficient expressive power too.
> >>>
> >>> All comments appreciated,
> >>>
> >>> 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/
> >>
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>
> >
> >
> > all the best, Don
>
>
> --
> *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/20170618/76e05456/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 18 Jun 2017 10:20:48 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
> Subject: Re: [x3d-public] Resource bound to operation.
> Message-ID: <30465783-809b-a43e-6289-2eb0eb853c9f at realism.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> John,
>
> I don't follow this at all. What would the 'open' and 'execute' methods
> do? There are too many different ideas I can think of for each
> statement, that I don't know where to begin.
>
> Leonard Daly
>
>
>
> On 6/16/2017 12:54 PM, John Carlson wrote:
> > Would it be possible to have SAI or Dom that operated like this:
> >
> > var key = scenegraphNode.open("delete");
> >
> > var keys_key = scenegraphNode.open("list");
> >
> > var key2 = node.open("get", "field1");
> >
> > var key3 = node.open("put", "field1");
> >
> > var key5 = key3.execute(keys_key);
> >
> > var keys_again = key2.execute();
> >
> > var list = keys_again.execute()
> >
> > key.execute();
> >
> > keys_key.execute(); // fails
> >
> >
> >
> >
> > _______________________________________________
> > 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/20170618/b8d64db4/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 99, Issue 45
> ******************************************
>

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/4052e954/attachment-0001.html>