[x3d-public] [x3dom-users] DEF to ID mapping

[Leonard Daly]

Andreas,

> Leonard,
>
> thanks for the background. This is very helpful. Let me see how I 
> understand the background.
>
> On Thu, Mar 24, 2016 at 11:37 AM, Leonard Daly <web3d at realism.com 
> <mailto:web3d at realism.com>> wrote:
>
>     Andreas,
>
>     When the XML encoding spec was written (about the turn of the
>     century now...) we anticipated the use of 'id' in nodes. It was
>     never used as a field name for that reason. [Note: I will use ID
>     instead of 'id' below.]
>
>
> Ok. it was anticipated that an additional id attribute was used in xml 
> (xhtml) nodes defining a x3d scene ? So there should be a way to make 
> such a scene spec. conforming ?
>
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html
>
> ID is the name of a data type.
>
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax
>
> DEF is an attribute of type ID.
>
>     It is good practice not to reuse names that must be unique within
>     a namescope/namespace, even external to that scope. So while there
>     are no explicit provisions preventing it, DEF names and ID values
>     should not appear within the same scene; however, I don't think it
>     can be stated that it is never the case.
>
>
> Well, currently, conforming x3d scenes cannot have an ID value, right 
> ? They can just have DEF values of type ID.

Rereading what I wrote, I realize that it is not clear enough. Trying 
again...

So while there are no explicit provisions preventing it, the names used 
for DEF and the values used for ID should be duplicated within the 
scene. E.g., DEF='foo' and ID='foo' (except for the same node) should 
not be used. Remember this is a recommendation and not a requirement.



>
>     DEF functions a little different than ID. DEF is name-scope
>     limited. Each X3D occurrence of a file defines its own name scope.
>     Also each PROTO or CreateX3dFromString/Url is its name scope. If
>     an X3D file contains DEF='foo' and it is Inlined multiple times,
>     each occurrence of 'foo' is different from any other occurrence of
>     'foo'. This is also a historical. Until X3DOM, X3D always ran in
>     it's own environment. In X3DOM, it is running in the DOM
>     environment. X3DOM takes care to prefix DEF names to prevent
>     collisions.
>
>
> Inlining the same file multiple times is a good case to consider. x3d 
> has IMPORT/EXPORT to avoid collisions, and x3dom has namespacename.

Correct IMPORT/EXPORT allow you to "rename" a name-scoped DEF name from 
child scene to the parent scene using a different DEF name in the 
parent's name scope

-- main.x3dv
DEF F1 Inline {url: "foo.x3d"}
IMPORT F1.bar AS f1Bar
DEF F2 Inline {url: "foo.x3d"}
IMPORT F2.bar AS f2Bar
DEF F3 Inline {url: "foo.x3d"}
IMPORT F3.bar AS f3Bar


--- foo.x3d
         :
         :
<EXPORT localDEF='FooNode' AS='bar' />
         :


So in 'main.x3dv' f1Bar refers to 'FooNode' in the first inline of 
foo.x3d. There are three separate copies of the foo.x3d content and each 
can evolve separately. The 'namespacename' attribute of the X3DOM 
<Inline ... /> node works the same way except there is no need to EXPORT 
anything from foo.x3d. The entire contents of foo.x3d is available to 
its parent. If there is no value for 'namespacename' then there is no 
DOM entry for those nodes. I do not know what happens if the main level 
Inlines a file1 without specifying namespacename and file1 Inlines file2 
and specifies namespacename.



>
>     For ID, what is needed is globally (within the HTML page) unique
>     values, including any Inlined, generated, or inserted nodes. I
>     don't think it is possible to require that across all X3D code.
>     Even if there was some sort of international registry, it would
>     still fail if an X3D file was Inlined more than once. X3DOM avoids
>     the name conflict issue by requiring the developer to create a prefix.
>
>
> It is necessary for ID to be unique on the web page (globally). Both 
> x3d and x3dom have mechanisms to make this easy for scene or web page 
> authors. In theorym x3dom could implement IMPORT/EXPORT instead of 
> using namespacename.
> It may a good idea to adopt namespacename in the x3d spec. as well.

This is a mater of philosophy. X3DOM allows the entire contents to be 
exposed to the DOM. IMPORT/EXPORT only allow what the Inlined node 
wishes to allow at the node level. It is not possible to control access 
at the field level unless the content creator takes special care during 
construction. OO languages usually provide mechanisms to reveal/protect 
variables and methods. Other languages (e.g., Perl) expose everything, 
but have adopted conventions to "protect" internal data. JavaScript (at 
least as of V5) is of the second category. I think X3D for HTML should 
follow the same conventions as the version of ECMAScript that is 
used/supported/required.



>
>
>     I think it would be good to only have a single node label. If you
>     have different values for DEF and ID, there is always the
>     confusion as to which one goes (or does) what. If they are the
>     same value, why have two labels.
>
>
> Completely agree. It does not make sense to have two labels for the 
> same function.
>
>     Perhaps DEF can be deprecated and ID be used going forward for all
>     encodings. If both are specified, then ID overrides DEF.
>
>
> Yes, this is the (big) question. If not for backward compatibility, I 
> think simply stop using DEF and instead using ID would help a lot.
> Perhaps, it is time take this fork in the road. The problem is it 
> would make all x3d scenes which use DEF invalid. Replacing all 
> occurrences of DEF with ID is not difficult, however.
>
> Another interim solution may be to define an implicit ID attribute in 
> the spec. which always has the value of the DEF field.
>
> To make this discussion more concrete, here is a proposal:
>
> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax
>
> could be amended by:
>
> A node instance can be given a label using the attribute DEF followed 
> by an equals sign and the quoted name of the node, as provided by the 
> DEF statement. In addition, for DOM compatibility reasons, an 
> additional attribute with the name ID is expressed implicitly which 
> has the same value. This ID attribute is not part of the x3d scene 
> graph but it is part of the fully parsed xml data structure and allows 
> access to the element by the DOM API.

In a quick review and think, I am not sure if the above statement causes 
a conflict with the definition of DEF in 19776-1 4.3.4 (link above). To 
me, something does not feel right. I am not sure if it is my lack of 
understanding and full appreciation of your statement or a premonition 
of a conflict or extra complexity.


Leonard Daly




>
> Feel free to criticize this proposal. Hopefully, the process can be 
> constructive.
>
> -Andreas


-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160326/a92dd171/attachment-0001.html>