[x3d-public] Validation improvements for "USE" attribute

Leonard Daly Leonard.Daly at realism.com
Thu Jun 15 10:58:54 PDT 2017


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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170615/d52783da/attachment.html>


More information about the x3d-public mailing list