[x3d-public] Inconsistencies in Requirement
Leonard Daly
Leonard.Daly at realism.com
Mon Jun 19 14:26:38 PDT 2017
Andreas,
Interesting points. I've added information I know (or found) embedded in
your comments.
>
> 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).
I have looked through the code and have not yet been able to find the
specific lines that deal with 'USE'. X3DOM does deal with 'USE' as can
be seen in the example at
https://examples.x3dom.org/example/x3dom_defUse.xhtml. View-source shows
that it is used in the second 'Shape'. I suspect that the second 'Shape'
is removed from the DOM but kept in the scene graph.
This particular method breaks (2 - not all X3D nodes are in the DOM). I
believe Andreas describes Cobweb as doing essentially the same thing.
>
> 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.
I have looked at the asset system in A-Frame, but not in sufficient
depth to determine whether
1) It uses the data as a single copy inserted into the DOM in the asset
statement with the uses not appearing in the DOM
2) It copies the information from the asset definition to the node that
uses it
3) It uses the asset-defined information by reference
If the asset system does not expand nodes in the DOM when it is used,
then it could very easily work like CSS by supplying a common definition
that other nodes just refer to (#3 above).
>
> 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.
Shadow DOM is (sort-of) like regular DOM. You are right about not
allowing multiple parents. It allows you to expose elements to the
(page) renderer without them being directly visible in the DOM. Since
the scene graph is roughly parallel to the DOM, adding another DOM seems
to me to be increasing the complexity without necessarily solving the
problem.
Even though it is 6 years old, this article provides a good basic
description of Shadow DOM -
https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
>
> I think SVG has DEF/USE as well. SVG then must define some exceptions (?).
Not being an SVG expert, I had to look this up. I found this Stack
Overflow questions:
https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use
It describes that the 'use' attribute does a deep clone and inserted
into the generated tree. Unfortunately, the answer did not provide a
reference, but it does look like it is quoting something important.
>
> Overall, it looks like it may be necessary to rely on more than the
> DOM alone for DEF/USE functionality.
Offering another possibility. Unreal (and I think Unity) create a class
for each object. If something is "copied", then it is sub-classed from
the original class. Changes to the parent propagate to all subclasses;
however, a sub-class can override any property (which would then
propagate to sub-sub-classes). I think that means in "X3D"-speak, the
"DEF" node defines the master class. Any node that "USE"s it would
create a subclass. A USE node could also redefine fields for that
subclass, and even make itself available for subclassing by using a DEF
statement. This would look something like:
<Transform DEF='Master' translation='1 2 3' rotation='0 1 0 0' scale='1
1 1'>...</Transform>
<Transform USE='Master'>...</Transform> <!-- strict subclass of Master -->
<Transform USE='Master' DEF='Alpha' rotation='1 0 0
1.57'>...</Transform> <!-- subclass of Master with a change of rotation -->
<Transform USE='Master' DEF='Beta' rotation='0 0 1
1.57'>...</Transform> <!-- different subclass of Master with a change
of rotation -->
<Transform USE='alpha' scale='2 2 2'>...</Transform> <!-- subclass of
Alpha with a change of scale -->
Leonard Daly
>
> 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
> <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
> <https://www.w3.org/TR/dom/#concept-node-tree> for the standard,
> >> https://www.w3.org/wiki/Traversing_the_DOM#Nodes
> <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 <mailto:x3d-public at web3d.org>
> >>> http://web3d.org/mailman/listinfo/x3d-public_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 <mailto:x3d-public at web3d.org>
> >> http://web3d.org/mailman/listinfo/x3d-public_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
> <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
> <mailto:Leonard.Daly at realism.com>>
> To: x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> Subject: Re: [x3d-public] Resource bound to operation.
> Message-ID: <30465783-809b-a43e-6289-2eb0eb853c9f at realism.com
> <mailto: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 <mailto:x3d-public at web3d.org>
> > http://web3d.org/mailman/listinfo/x3d-public_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
> <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 <mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_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
>
>
> _______________________________________________
> 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/20170619/a158b525/attachment-0001.html>
More information about the x3d-public
mailing list